Removing text in the HTML composer changes current font

UNCONFIRMED
Unassigned

Status

Thunderbird
Message Compose Window
UNCONFIRMED
6 years ago
3 years ago

People

(Reporter: C. Schreiber, Unassigned)

Tracking

15 Branch
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: dupme?)

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

On a fresh profile in Windows XP :
1) In the "Composing" option tab, set the default font to "Courrier" (not "Courrier New").
2) In the "Display" option tab, uncheck "Allow messages to use other fonts".
3) Compose a new mail and click in the editor area : current font is "Courrier", as expected.
4) Write some text : current font automatically switches to "Fixed width".
5) Remove some text (either by pressing "Backspace", "Delete", or by selecting some text, right-clicking it then choose "Remove") : current font goes back to "Courrier".

(note that I use a French client, so my translations for UI elements are approximative)


Actual results:

Although troubling, this "font oscillation" doesn't seem to have any impact on the message being composed. The font that renders text in "Fixed width" looks exactly like "Courrier" (even though it is supposed to be "Courrier New", which is the default fixed width font here on Windows XP).

The real problem comes from the generated HTML code : each time the font changes this way, a new <font> tag is generated, with the very same argument : <font face="Courier New, Courier, monospace">. This is horribly wrong because if you happen to type "Hello you", press backspace so that you only have "Hello", then type " darling" (mind the space), then the space before "darling" gets removed when the message is sent (and not before, so you never see it before it's too late). The generated HTML code is :
    <font face="Courier New, Courier, monospace">Hello<font
        face="Courier New, Courier, monospace"> darling</font><br>
    </font>

Several other issues, probably related (all with the settings described above) :
1) Choosing the current font as "Courrier" in the HTML composer automatically selects "Fixed width".
2) Choosing the current font as "Courrier New" in the HTML composer displays text with a variable width font.
3) Write some text (default font is then "Fixed width", as described above, and text shows with "Courrier" font as expected), and remove *everything* (that is important). The font is now back to "Courrier". Type new text : the current font remains "Courrier" this time, but it is displayed with a variable width font...


Expected results:

The "Courrier" font being chosen as a default, it should have remained the current font during the whole process, because none of the actions above are supposed to change the current font, as far as I know.

Temporary work around : leave "Allow messages to use other fonts" checked.
(Reporter)

Comment 1

6 years ago
I tested this on Ubuntu with another profile and the same thing happens (except the other issues 2) and 3), surely because Ubuntu does not have "Courrier New"), so this is not a Windows only bug.
Does the same thing happens in http://www-archive.mozilla.org/editor/midasdemo/ ?
(Reporter)

Comment 3

6 years ago
No, since there is no way to select the same preference options that actually trigger the bug in Thunderbird (or maybe there is?).
The important combination is to:
1) disable custom fonts in all emails,
2) choose Courrier as default font for writing emails.

No matter what monospace (fixed width) font one imposes in 'Display -> Formatting -> Advanced'.
This sounds somehow familiar.
Whiteboard: dupme?
(Reporter)

Comment 5

6 years ago
I could not find a similar bug report here, but maybe I didn't search for the right words.

Comment 6

6 years ago
The problem has become worse in the latest versions of TB (after 14). Font changes occur even after sending/saving a message; Although in the compose window the font and font size appears uniform (the default selected), when the message is saved/sent, it has turned into a mess (multiple fonts with multiple sizes).

So the author cannot see his/her message format is being changed by TB to correct it! 

Even after re-opening the draft, selecting the whole content and forcing a font, does not solve the problem. 

See attached screenshots and message sources.

Comment 7

6 years ago
Created attachment 685557 [details]
Displays a message saved as a draft after initial composition. The text in the message describes how it was composed.

A test message composed to illustrate how TB changes fonts.

Comment 8

6 years ago
Created attachment 685561 [details]
The source of the initial test message as saved in the drafts

Displays the HTML source of the test message, as initially saved in the Drafts folder.

Also shows how bad HTML code is: many tags inserted at various locations - no HTML optimization.

Comment 9

6 years ago
Created attachment 685563 [details]
Test message opened/edited and re-saved in the Drafts

Shows how the message is formatted, even though we explicitly applied "Palatino Linotype" after selecting the whole initial text.

Comment 10

6 years ago
Created attachment 685564 [details]
The source of the test message after editing and resaving in Drafts

The HTML content is even more complex.

Comment 11

6 years ago
Please correct this irritating bug, as we cannot compose a decent message any more; we don't know how it will look like in the end!

Thanks,

Comment 12

6 years ago
Although this is a chronic problem with TB editor, it has recently aggravated.

See older references of the problem: 

http://www.makeuseof.com/answers/thunderbird-switch-fonts-stop/
http://forums.mozillazine.org/viewtopic.php?f=39&t=1790755
https://getsatisfaction.com/mozilla_messaging/topics/font_keeps_changing_as_i_type

It is a widely known bug.

It seems most users resort to the QuoteandCompositionManager extension to keep fonts from changing. I have finally resorted to that too and it works, but TB should be fixed anyway.

Comment 13

6 years ago
The problem persists with version 17.0
Duplicate of this bug: 842187
You need to log in before you can comment on or make changes to this bug.