129.36 KB, image/jpeg
40.49 KB, image/png
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; (R1 1.5); .NET CLR 2.0.50727) Build Identifier: 184.108.40.206 (20070604) When I set default HTML fonts in Tools ... Options ... Composition ... HTML, these work fine until I use bullet points or another type of list, at which point the fonts switch back to serif (Times in my case). This is very annoying, and would seem to be inconsistent. The only workaround I've found is using Insert HTML and then a CSS formatting tag to alter the Variable Width font setting, but as your own KB wiki points out, this must be done _every time_. I can't imagine that a lack of a consistent default font setting is considered a feature, and indeed it's pretty annoying to anyone used to the UI of any commercial product: a shame for an otherwise good OS program. Reproducible: Always Steps to Reproduce: 1. Set default HTML font to Arial, set composition to HTML 2. Start writing new msg, font will be Arial. 3. Start a bulleted list, font switches off Arial. Actual Results: font switches off Arial. Expected Results: font should stay Arial, noone sets a default for the pleasure of the editor deciding for them that it knows better. This is a basic UI issue, and UI too often gets short shrift in OS projects. Please prove me wrong on that.
I confirm this bug, very annoying indeed.
I'm encountering a similar issue. The text format (font type and size) stays the same as defined by me in the default settings in the bullet-point list, but changes to Arial and variable width AFTER the bullet points... This change becomes visible only when looking at the message in the Sent Items folder (not in the compose window).
I cannot confirm on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20090708 Lightning/1.0pre Shredder/3.0b3pre ID:20090708034418 Reporter the issue is still present also in last release 18.104.22.168?
Yes, I strongly confirm that this issue is still present in Thunderbird 22.214.171.124 (and is annoying me me every single day). Furthermore I think there is basically something wrong with the way Thunderbird handles the fonts. Whatever font is selected, the sender's editor always shows the same font family.
You can attach a screenshot of your "Fonts & Encoding" window that you can see on menu-->Tools-->Options and (in TB I'm not sure) tab "Display" -->"Formattings" button "Fonts"?
Created attachment 387622 [details] Thunderbird: Tools > Options > Display > Formatting > Tab "Fonts and Encoding" Here is a screentshot of the tab. Although my native language is German I don't understand the options here.
I cannot reproduce issue on TB3 beta also with your same fonts option, but I remember something similar to your bug when I used TB 1.5 or 2.0. Can you try with beta release? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/
Created attachment 387666 [details] TB3 Screenshot "Composition of a new mail with different font styles" Unfortunately the discussion above drifted away from the original issue. I should not have added the "furthermore" comment, sorry. I tried with TB3 beta as you suggested. As you can see in the attachment, the issue still persists. The issue is: -> select your favourite font-family and font-size in the tools > options menu (in my case it is "Trebuchet small" -> compose a new mail and begin writing text. The font style is "Trebuchet small". Very good so far. -> click the "bulleted list" icon and go on writing. The font style has automatically changed to "Variable width medium" which in this case obvisously is "Times New Roman" -> the same happens if you click the "numbered list" icon or if you insert a table. The font changes automatically. Thee only workaround as far as I know is, you select the whole text before sending it and then select the font-family and font-size. That is what's annoying me so much. If your forget doing this, the receiver will get an ugly looking mail with different font styles and will probably think you are a computer amateur. I do hope this bug will be fixed soon. Thank you.
It seems a duplicate of bug #250539