Incorrect font displayed in dropdown during HTML mail composition

RESOLVED DUPLICATE of bug 209674

Status

MailNews Core
Composition
RESOLVED DUPLICATE of bug 209674
14 years ago
10 years ago

People

(Reporter: Greg Chakalian, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

({regression})

Trunk
x86
Windows 98
regression

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

The selected mail font (MS Sans Serif), custom set in "preferences", does not
consistently display correctly when replying to an email or composing a NEW
email. When it does not display per preference it displays the "Times New Roman"
default, but indicates MS Sans Serif as the current font in the font drop down menu.

Reproducible: Sometimes

Steps to Reproduce:
1. Compose a new email or reply to an existing one.

2. Also, in a case, where different fonts are used within the body of the email,
highlighting a specific character does not display/indicate the correct font in
the font drop-down menu. The listed font in the drop-menu should switch to and
indicate the respective character/font highlighted with the cursor.
Actual Results:  
Incorrect font displayed

Expected Results:  
Correct font should be displayed

Comment 1

14 years ago
Greg Chakalian, this could be a character-set issue.

In  Preferences|Mail&Newsgroups|Composition, there is a setting for the 
character coding -- typically "Western (ISO-8859-1)" or "Unicode (UTF-8)".  Each 
individual character coding has its own specific set of fonts; if you look at 
Preferences|Appearances|Fonts, you'll see the dropdown to select the encoding at 
the top.  Be sure when you're setting the font, you're matching it to the 
encoding used for mail composition.

If this information fixes your problem, please mark this bug  Resolved|Invalid.
Summary: Incorrect font outputted/displayed during mail compostion or reply → Incorrect font outputted/displayed during mail compostion or reply

Comment 2

14 years ago
No response from reporter; =>WFM

Greg Chakalian, if this bug is still a problem for you after trying the 
suggestions in comment 1, feel free to reopen.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

14 years ago
The coding is and has always been ISO-8859-1. The problem appears to be
inconsistent. Notably, the font in the composition drop-down menu is not
indicative of the font hi-lighted when multiple style fonts are used. This is
almost always consistent and may be a bug of it's own. It will often indicate
"(mixed)"  no matter what is selected with the pointer/cursor or simply show the
incorrect font. Will pay closer attention to see if this follows any particular
pattern or sequence.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 4

14 years ago
My mistake: I was assuming you were using plain text, rather than HTML mail, and 
so I misread the bug.  Sorry!

This is a regression between 1.3 and 1.4.  (Perhaps a side effect of the fix for 
bug 107877.)

The font-select dropdown is not dynamically updated to indicate the font in use 
at the cursor point or selection.  If a selection is made that includes multiple 
typefaces, the dropdown does update to "(mixed)" but then remains at that 
setting.  Changing the dropdown manually still works to reset the font, but when 
the cursor is moved to a different point, text entered there uses the font 
settings from that point.

Note that the Style dropdown, and the color and BUI indicators, all update 
dynamically as expected.

If there's an earlier report, I've missed it.  Updating summary for clarity, and 
confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: Incorrect font outputted/displayed during mail compostion or reply → Incorrect font displayed in dropdown during HTML mail composition

Comment 5

14 years ago
This appears to be a dupe of bug 209674.  Greg, do you agree?
(Reporter)

Comment 6

14 years ago
It appears so. Was able to replicate bug 209674 and it was consistent with bug
223877.  The issue is not specific to a particular font. I may not have been
clear in the earlier bug report that indicated MS Sans Serif.

Comment 7

14 years ago
OK, marking dupe.

*** This bug has been marked as a duplicate of 209674 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.