Closed Bug 103282 Opened 18 years ago Closed 18 years ago

font size in reply window can't be changed when encoding is changed.


(MailNews Core :: Internationalization, defect, major)

Not set


(Not tracked)



(Reporter: bertilow, Assigned: nhottanscp)



(Keywords: intl)


(4 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20011003
BuildID:    2001100308

When I reply to postings that use ISO-8859-3, the reply window
comes up set too a ridiculously small font, and there is no
UI to change it. None of the font settings in the preferences
are used. ISO-8859-3 does not have it's own entry in the font
settings. Normally it follows the settings for ISO-8859-1, but
in this case not. Instead some extremely small font that comes
from I-don't-know-where is used. I have to edit my replies with
a magnifying glass! (OK, not really, but almost...)

At least the reply edit window should have the usual text zoom
feature, but it's nowhere to be seen.

This does not happen in the Windows builds.

Reproducible: Always
Steps to Reproduce:
1. Find a news posting in ISO-8859-3.
2. Hit reply.

Actual Results:  The quoted message (and any text entered) is displayed
in a font that is not desired, and that can not be changed.

Expected Results:  The font used should be the ordinary one used for messages
encoded in ISO-8859-3.
Keywords: intl
Reassign to nhotta.
I do not see the small text in either viewing the original message or the
replying message.
There is a way to add ISO-8859-3 to messeage compose menu by using the customize
dialog in character coding menu. Could you try that?
In my case, I did not have the small text problem with and without adding
ISO-8859-3 to the menu.
Assignee: yokoyama → nhotta
I already have iso-8859-3 in that menu. When the reply window
is already opened, changing the encoding does not change the
font or the size. It remains tiny.

On closer inspection I found that the font used is in fact
the one chosen for iso-8859-1 (but it is shown in such a
tiny version that it's hard to recognize it). It is the
right font, but not the right size.

This happens in mail too, but I seldom receive mail in

I can also change the encoding of any message to iso-8859-3
_before hitting reply_. The reply window comes up with the
tiny print.

This does not happen for me in other circumstances. 
Reading messages, creating messages, preview pane, separate
window - all get the right size font. Only "reply", "reply all"
and "edit as new" get this annoying behaviour. And all those
windows share the same peculiar lack of a text zoom menu item!

I've tried various fonts for Western monospace, and various
sizes. The fonts selected for replies to iso-8859-3 always
follow this choice but the size remains some tiny version.
Exactly how tiny it gets varies a little. Some fonts get a
really ridiculous version. Others get some slightly more
reasonable tininess.
When you see the tiny display, select all and copy it then paste into mozilla
HTML editor. Then you can see the source and know what font is actually used.
Could you try that?
Weirder and weirder...

I copied the text into the HTML editor. It was displayed in a
normal size there, with a proportional font - the default one
for the HTML editor. The HTML code had no font info, none at
all. BUT!, in the HTML source mode the source for the message
was displayed in the same tiny font that I'm complaining about!
It turns out that the very same problem is present in the source
view of the HTML editor. But then there is no connection to

What option sets the font to be used in the source view in the
HTML editor? For me it's always a supertiny version of 
the monospace font for Western.
I use Mozilla under KDE. Just to be sure I bumped up all of my
font settings in KDE a couple of notches, and restarted Mozilla.
But there was no difference.
Could you attach a screenshot so I can confirm the bug?
The first screen shot shows two reply windows. One has the
tiny font. The preview pane below shows that same message
using the correct size font.

The second screen shot shows the source view in Composer.
BTW. To really see this effect I suppose you have to use quite
large font settings. If your ordinary settings are small already
the difference might not be that big. Crank up the monospace font
for Western to 20, then the difference will show up (I hope...).
Ever confirmed: true
My testing so far was on Windows. The problem might be Unix font related.
Brian, could you take a look at this?
Assignee: nhotta → bstell
This is probably Unix/Linux only. I've used Mozilla a lot on
Windows 98, and I've never seen anything like this. I only
recently switched to Linux, and now this happens all the time.
Montse has found a similiar problem when replying to an ISO-2022-JP mail and I 
was able to reproduce with windows 10/05 0.9.4 build.
To see her problem,
1. From Preference, change fonts for Japanese to a much bigger fonts, say 
size of 20.
2. Compose an English mail but sent out in ISO-2022-JP encoding.
3. After the mail is received, click on Reply.
4. On the reply window, selecting charset menu to Western (IS0-8859-1), now the 
reply mail is changed to iso-8859-1 encoding.
5. Enter something in mail body of reply window.
   You'll see the letters you entered in reply window are displayed in the fonts 
you selected for Japanese, not the one you desired for iso-8859-1. 
Montse didn't see this problem when switching to 6.1, so it's a regression.
Keywords: regression
nominating and changing platform to all since i see it in windows NT
Keywords: nsbranch
OS: Linux → All
what are the chances this will make the 094 branch?

pls set priority and target milestone.
Severity: normal → major
Whiteboard: [Need ETA]
Reassign to nhotta since this is not Unix specific.
Cc to ducarroz, putterman.
Assignee: bstell → nhotta
I can reproduce the problem with 6.1 following steps posted above. Need to check
with Montse for her problem since she can't see her problem using 6.1.
Confirmed with Montse, it has been an ugly bug since the beginning, including 6.1. 
Keywords: regression
Then this is not a regression, and should be considered fir nsbranch- by GCT for
the 094 branch (i.e. This is not a stop ship since 6.1 shipped this way)
unfortunately, you're right. Marking nsbranch-. Need to address in next release
Keywords: nsbranchnsbranch-
The patch notifies the charset change by the menu to editor.
Editor has to refresh and change the font according to the new charset. That is
filed as a separate bug 103678, mark this bug to depend on that.
Depends on: 103678
Comment on attachment 52640 [details] [diff] [review]
Patch, in mail compose, notify charset change to editor.

Attachment #52640 - Flags: review+
Comment on attachment 52640 [details] [diff] [review]
Patch, in mail compose, notify charset change to editor.

sr=bienvenu - as long as this doesn't do any extra work in the case where the editor charset isn't changing.
Attachment #52640 - Flags: superreview+
Checked in to the trunk.
Need editor side change.
Whiteboard: [Need ETA]
Target Milestone: --- → mozilla0.9.7
Summary: font size in reply window can't be changed for some encodings → font size in reply window can't be changed when encoding is changed.
Blocks: 107067
Keywords: nsbranch-
move to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Added nsbeta1 keyword.
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1+
No longer depends on: 103678
For editor, there is a code which loads the document after the charset change.
489 function EditorSetDocumentCharacterSet(aCharset)
490 {
491   if(editorShell)
492   {
493     editorShell.SetDocumentCharacterSet(aCharset);
494     if( !IsUrlAboutBlank(editorShell.editorDocument.location))
495     {
496       // reloading the document will reverse any changes to the META 
497       // we need to put them back in, which is achieved by a dedicated 
498       editorShell.RegisterDocumentStateListener( DocumentReloadListener );
499       editorShell.LoadUrl(editorShell.editorDocument.location);
500     }
501   }
502 }

But the mail compose code cannot use it because it is "about:blank" and if we 
load we lose the typed data. So need a way to reset the font info without the 
Hardware: PC → All
I experimented to get a font face from a charset then set to the editor. It 
works but we don't want to send out the face name with the message.
So I start to think again this has to be done in editor (bug 103678).
I got helps from people. There is a code in nsPresContext which responds to the
document charset change, there we can update the font and reflow. This is
similar to what happens when the font is changed by prefrence UI, that also
update the font and reflow.
Not sure who is the owner of nsPresContext. I will ask attinasi for sr but I
need 'r=' first.
Simon, could you review the last patch?
Attachment #61672 - Flags: review+
Comment on attachment 61672 [details] [diff] [review]
Chagned nsPresContext::Observe, in case of charset change added code to flush font and reflow.

Comment on attachment 61672 [details] [diff] [review]
Chagned nsPresContext::Observe, in case of charset change added code to flush font and reflow.

Looks right - sr=attinasi
Attachment #61672 - Flags: superreview+
checked in
Closed: 18 years ago
Resolution: --- → FIXED
Verified as fixed with 03/20 builds.
Product: MailNews → Core
Product: Core → MailNews Core
Depends on: 537404
You need to log in before you can comment on or make changes to this bug.