Open Bug 1265186 Opened 8 years ago Updated 1 year ago

selecting "Courier 10 Pitch" in TB composer font picker selects "Courier"

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Linux
defect

Tracking

(Not tracked)

People

(Reporter: aceman, Unassigned)

Details

In the Thunderbird composer's font picker (HTML mode) I choose a font like "Courier 10 pitch". But instead the font "Courier" (that was also in the list) is selected.

But in the composed message, there is the right font used (<font face="Courier 10 Pitch"> can be seen in the msg source when saved as draft).

This seems to happen for all fonts that have a number as a separate word in their name, e.g. "Wingdings 2" (changes to Wingdings). But not with "Nimbus Roman No9 L"
After choosing and applying the right font, for some reason, for those mentioned fonts, onFontFaceChange() in editor.js is last called with the fallback (courier, wingdings) font. That call is not there for other fonts. As if something outside of the user font selection is changing the font value to a different value (changing the attribute on cmd_fontFace element thus initiating onFontFaceChange()).
Yes, I can reproduce with "Anastasia Extended 1". Display becomes "Anastasia Extended (not installed)".
HTML: <font face="Anastasia Extended 1">text<font face="Anastasia Extended 1">text</font></font>
Not nice to have a double-font here.
M-C editor bug:
==== returned from M-C: Anastasia Extended 1
==== returned from M-C: Anastasia Extended
and
==== returned from M-C: Anastasia Extended 2
==== returned from M-C: Anastasia Extended

On a new paragraph I get the former, when typing the latter.
Better debug to see the white-space or absence thereof:
==== returned from M-C: |Anastasia Extended 1|
==== returned from M-C: |Anastasia Extended|
I'd say this is a variation on bug 268376.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.