62756 - Text of displayed HTML messages very small

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

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

[Mike Pinkerton (not reading bugmail)]

Attachment: small text

Comment 2

[Mike Pinkerton (not reading bugmail)]

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

Comment 3

[Asa Dotzler [:asa]]

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
this?

Comment 4

[Mike Pinkerton (not reading bugmail)]

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

Comment 5

[Mike Pinkerton (not reading bugmail)]

Attachment: msg source of a msg that displays tiny tiny text

Comment 6

[Mike Pinkerton (not reading bugmail)]

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

Comment 7

[Mike Pinkerton (not reading bugmail)]

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.

Comment 8

[scottputterman]

marking nsbeta1+ and moving to mozilla0.9.1

Comment 9

[[e-mail]]

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

Comment 10

[scottputterman]

Moving to 0.9.2.  My understanding is that the default font prefs work ok.

Comment 11

[scottputterman]

moving to 0.9.3

Comment 12

[Simon Fraser [no longer active]]

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)
</div>

where the font-family, and the font-size are deduced from your preferences. This 
was work done for bug 38890 and bug 40547; see
http://lxr.mozilla.org/mozilla/source/mailnews/mime/src/mimethtm.cpp#67

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.

Comment 13

[nhottanscp]

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 
mail?

Comment 14

[Håkan Waara]

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

Comment 15

[Simon Fraser [no longer active]]

> 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

[nhottanscp]

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 
size.

Comment 17

[nhottanscp]

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

Comment 18

[scottputterman]

reassigning to ducarroz until we decide if mailnews isn't the right owner.

Comment 19

[[e-mail]]

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

Comment 20

[nhottanscp]

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

[Simon Fraser [no longer active]]

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

[nhottanscp]

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?

Comment 23

[Jean-Francois Ducarroz]

Yes, we are currently inserting our own (mailnews) css file in each message display.

Comment 24

[nhottanscp]

Attachment: Patch, changed not to generate less than 100% font size.

Comment 25

[nhottanscp]

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 [e-mail].

Comment 26

[nhottanscp]

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.

Comment 27

[nhottanscp]

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

[nhottanscp]

Attachment: Patch, disabling font scaling in libmime.

Comment 29

[nhottanscp]

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.

Comment 30

[Jean-Francois Ducarroz]

R=ducarroz

Comment 31

[(not reading, please use [e-mail] instead)]

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

[nhottanscp]

Attachment: Patch, removed font-size.

Comment 33

[(not reading, please use [e-mail] instead)]

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

[nhottanscp]

I think we want to keep the argument in case for the unicode font problem is
fixed (bug 91190).

Comment 35

[(not reading, please use [e-mail] instead)]

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

[R.K.Aa.]

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

Comment 37

[nhottanscp]

Checked in to trunk.
The change is not for Macintosh specific.

Comment 38

[nhottanscp]

Fixed in trunk.

Comment 39

[[e-mail]]

A sight for sore eyes!