Text of displayed HTML messages very small

RESOLVED FIXED in mozilla0.9.3


18 years ago
10 years ago


(Reporter: mikepinkerton, Assigned: nhottanscp)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta1+])


(5 attachments)



18 years ago
Since I upgraded from the NS6 release bits, i've noticed that the text in
messages is so small, it's almost unreadable.

I'll attach a screenshot. This makes it really hard to use.

Comment 1

18 years ago
Created attachment 20596 [details]
small text

Comment 2

18 years ago
note that my fonts are set at 12pt (default is higher), but webpages are all
still readable. It's only email.


18 years ago
QA Contact: esther → pmock

Comment 3

18 years ago
I'm not seeing this with my mac build 030608.  If I set font to 12 webpages
become pretty difficult to read but mail looks fine.  Mike, are you still seeing

Comment 4

18 years ago
plaintext messages are ok, it's people that send html mail.

Comment 5

18 years ago
Created attachment 27306 [details]
msg source of a msg that displays tiny tiny text

Comment 6

18 years ago
and yes, this does happen with my 3/9/01 build

Comment 7

18 years ago
now that mail is usable, I'd love to see this fixed since it makes my eyes bleed
to read the tiny text. 

Hey Seth, if you fix it in moz0.9 i'll buy you a 6pack of whatever you want.
Keywords: mozilla0.9, nsbeta1, nsCatFood, nsdogfood


18 years ago
Keywords: nsCatFood → nsCatFood+
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1

Comment 8

18 years ago
marking nsbeta1+ and moving to mozilla0.9.1

Comment 9

18 years ago
*** Bug 70598 has been marked as a duplicate of this bug. ***

Comment 10

18 years ago
Moving to 0.9.2.  My understanding is that the default font prefs work ok.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 11

18 years ago
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 12

18 years ago
Seth and I looked at this for some time today. Here's the deal:

On message display, the MIME code wraps the message in a 

<div class="moz-text-html" style="font-family: Times; font-size: 100%">
(message body here)

where the font-family, and the font-size are deduced from your preferences. This 
was work done for bug 38890 and bug 40547; see

The problem here is that Pinkerton and I have set our font prefs to use 12px as 
the fize for our variable-width font. The code in GetMailNewsFont() compares the 
font sizes in the user prefs and default prefs (12px and 16px respectively) to 
determine the font-size percentage, which thus comes out as 75%. So the message 
is displayed at 75% font size.

It's not clear why this <div> needs font-size style on it at all. Removing the 
font-size attribute seems to work, but may break i18n stuff that nhotta was 
trying to fix in the first place.

nhotta: please take a look at this bug.
Assignee: sspitzer → nhotta
Component: Mail Window Front End → MIME
QA Contact: pmock

Comment 13

18 years ago
This was done to allow the user to change the mail font size by the font
preference, so it's not i18n.
Removing the size attribute would disable the ability to change message view
font size. I think some people may need larger font size.
Reassign to putterman for evaluation, can we disable the size attribute for 
Assignee: nhotta → putterman

Comment 14

18 years ago
This should probably go to ducarroz, owner of the MIME module.

Comment 15

18 years ago
> This was done to allow the user to change the mail font size by the font

But don't the contents of the <div> render using the users preferred font
settings already?

Comment 16

18 years ago
Yes, but it uses the font size of unicode because libmime sends UTF-8 data to 
layout. So, I have to correct my last comment. After removing the font size 
attibute, there is a way to change message font size by changing unicode font 

Comment 17

18 years ago
If samll size is the problem then I can prevent generating less than 100% sizes.

Comment 18

18 years ago
reassigning to ducarroz until we decide if mailnews isn't the right owner.
Assignee: putterman → ducarroz

Comment 19

18 years ago
So what you're saying is that the font scaling gets applied twice?

Comment 20

18 years ago
I don't think it's applied twice. If font size is not specified, it is taken
from the pref based on the charset of the document.

Comment 21

18 years ago
These <div>s that we insert into displayed messages are also problematic in 
general. The get included in copy/pasted text, which means that doing a Select 
All/Copy/Paste of the contents of a message gives you some content that was not 
in the original message. And doing this repeatedly, as I have seen people do in 
standard format emails, causes this <div> to appear multiple times.

Can we move this font-related CSS into the XUL?

Comment 22

18 years ago
I am not sure about moving the CSS into XUL, if that possible or not.
But can the size issue be resolved by moving to XUL?
Yes, we are currently inserting our own (mailnews) css file in each message display.

Comment 24

18 years ago
Created attachment 42413 [details] [diff] [review]
Patch, changed not to generate less than 100% font size.

Comment 25

18 years ago
With the patch, libmime always generates font size 100% or larger. But HTML
messages are still displayed smaller when the font is set to smaller size by
pref UI. It seems like somewhere else setting the font size.
It could be related to bug 90474, cc to attinasi@netscape.com.
Summary: Text of displayed messages very small → Text of displayed HTML messages very small

Comment 26

18 years ago
The problem is that unicode font size is affected by font size setting of Western.
This can be reproduced by browser by using charset menu to change the charset to
UTF-8 for HTML pages.
Because of this problem, the message display (charset is UTF-8) is scaled by
Western font size. But the scaling is already done by libmime, therefore we get
the double-scaled problem.
So the problem is probably related to font/layout, reassign to nhotta for now.
Assignee: ducarroz → nhotta

Comment 27

18 years ago
There is a code in layout (which calls i18n) to use font of the default locale
in case the document is unicode (e.g. UTF-8). That was done in order to make XUL
(charset is UTF-8) to use the default locale instead of using the unicode font.
This creates the side effect. In browser, locale font size (Western in case of
US system) is used for Unicode pages. In mail, it causes the double scaling
problem because libmime specifies font size and the font is scaled again because
the mail output is UTF-8.

Comment 28

18 years ago
Created attachment 42612 [details] [diff] [review]
Patch, disabling font scaling in libmime.

Comment 29

18 years ago
I filed a separate bug about the unicode font as bug 91190.
The current behavior was done by intention and currently I do not have a solution.
For mail/news, I put a patch of disabling the scaling in libmime. This disables
the support of per language based scaling. And mail font size is controlled by
the default locale font setting (e.g. Western for US system). I think this is
fine for most people.
if we are going to do that, why not remove the "font-size: %d%" part completely?

and something that sfraser and I noticed, why isn't it:

"font-size: %d%%"

both ways seem to work, but isn't "%%" correct?


Comment 32

18 years ago
Created attachment 43005 [details] [diff] [review]
Patch, removed font-size.
looking at the other callers of GetMailNewsFont(), the one in mimethtm.cpp was
the only one using fontSizePercentage (last arg to GetMailNewsFolder())

if that isn't going to be used anymore, we should clean up GetMailNewsFolder()
and the callers, right?

see http://lxr.mozilla.org/mozilla/search?string=fontSizePercentage

Comment 34

18 years ago
I think we want to keep the argument in case for the unicode font problem is
fixed (bug 91190).
ok, good to know.  

if we plan on using it for something later we should obviously keep it in.

sr=sspitzer on the last patch.

thanks for fixing this nhotta.    pinkerton, sfraser and other mac users are
going to be very pleased.

Comment 36

18 years ago
This is a severe problem also under Linux. Is it now fixed for Mac only??

Comment 37

18 years ago
Checked in to trunk.
The change is not for Macintosh specific.
OS: Mac System 9.x → All
Hardware: Macintosh → All

Comment 38

18 years ago
Fixed in trunk.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 39

18 years ago
A sight for sore eyes!


16 years ago
QA Contact: esther
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.