90474 - Fixed font size pref has no effect on CSS font-family: monospace

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Ben Bucksch (:BenB)]

Reproduction
1. Load bugzilla bug
2. Increase Prefs|Fonts|Western|Monospace|Size (I tried Unicode and User
Defined, too.)
3. Check bugzilla bug again. (Reload to be sure, you may even restart)

Actual result
After step 1: The comments are almost unreadable small (for me)
After step 3: No change.

Expected result:
After step 1: Comments are readble (other bug).
After step 3: The comments are shown exactly in the size that I chose.

Additional Comments:
Changing the backend-prefs
pref("font.size.fixed.x-unicode", 14);
pref("font.size.fixed.x-western", 14);
directly in defaults/prefs/unix.js *does* have an effect, so it's a UI problem.

This is a recent regression, I think. In any case, it got much worse, because
the default size decreased.

Comment 1

[nhottanscp]

Reassign to jbetak, cc to bstell.
Cc to IQA, please check if this is also reproducible with the branch, also check 
if this is Linux only, thanks.

Ben, by changing font size in UI, does the backend pref value also change?

Comment 2

[Ben Bucksch (:BenB)]

hm, you're right,

user_pref("font.size.fixed.x-user-def", 16);
user_pref("font.size.fixed.x-western", 15);

gets written to my prefs.js. But it's not used. Odd. (I hope, it's not only a
local phenomenon.)

Comment 3

[ji]

Yuying and I checked this on branch builds. It happens on windows and Mac too.
Changed the platfrom to all. In our case, it only happens when changing fixed 
font size for Unicode. Western and user-define don't have this problem.

Comment 4

[sairuh (rarely reading bugmail)]

is this limited to changing the font size for languages other than Western? just
wondering...

changing qa to teruko for now, as i'll be going on vacation in the next few days
and might not be able to test this for some time...

Comment 5

[Teruko Kobayashi]

Changed QA contact to [e-mail]

Comment 6

[[e-mail] (away - not reading bugmail)]

targeting 0.9.3, accepting...

Comment 7

[[e-mail] (away - not reading bugmail)]

this bug has me wondering as well... First of all - is this a regression, if 
so, do we have any idea, when it started appearing? 

Another comment: I don't believe that the page Ben was looking at, is using any 
fixed (monospace) fonts, so adjusting their size won't affect the presentation. 

Ben, could you please make a screenshot of your font preference panel and 
attach it to the bug? Preferably, take a snapshot of both Unicode and Western 
encodings.

My current belief is that this bug indicates incorrect usage of the font pref 
panel, but I'd love to be proven wrong!

Comment 8

[Gervase Markham [:gerv]]

Anecdotally, I think this is a bug - I've seen it when messing with the fonts
prefs panel, but never got around to reporting it.

Gerv

Comment 9

[Katsuhiko Momoi]

I have a similar but not the same problem for Mail viewing
in Japanese. I filed Bug 90792 for it. The problem does not
get resolved whether I use fixed font or variable font for
viewing mail.

Comment 10

[Marc Attinasi]

You should check if this is a regression from the new Style Rule landing of
06/01 - if it works on a 05/30 build nut not on a 06/01 build, then this is
probably due to the Rule Tree not being rebuilt as a result of the pref rules
being changed. See also bug 90081

Comment 11

[Frank Tang]

I am using m92 20010711 win branch build. I can reproduce this. Not only to the 
fixed font size, but also the propotional font size.
The font size won't change untill you manually reload it.
It supposed to refresh the page once you hit the OK in the font pref. 
I can observer it refresh the page, but somehow it does not refresh the page 
with the new size. Again, this bug at least can be reproduce on window also.
Not sure about Mac. This bug impact not only monospace font, but also 
propotional font size.

Comment 12

[Ben Bucksch (:BenB)]

> The font size won't change untill you manually reload it.

With the bug as I reported it, the size will never change, not even after a restart.

Comment 13

[[e-mail] (away - not reading bugmail)]

ftang, Marc:

confirming regression, I just tried 05-05 and 06-01 builds. The bug as 
described by ftang occurs in the 06/01 build, but does not occur in the 05-05. 
We still need to get an 05-30 build to confirm dependency on bug 90081.

Comment 14

[Frank Tang]

I try the following build in ylong's machine.
window 20010523 0.9+ 6.5b0 build- no problem 
window 20010612 0.9.1+ 6/6.1b1 build- has the problem
jbetak said he try window 20010601 build - has the problem

Comment 15

[Frank Tang]

We also try it in jbetak's debug build. We set a break point in 
mozilla/layout/base/src/nsPresContext.cpp:
204 nsPresContext::GetFontPreferences()

...
236 if (!PL_strcmp(unit, "px")) {
237 float p2t;
238 GetScaledPixelsToTwips(&p2t);
239 mDefaultFont.size = NSFloatPixelsToTwips((float) variableSize, p2t);
240 mDefaultFixedFont.size = NSFloatPixelsToTwips((float) fixedSize, p2t);
241 }
242 else if (!PL_strcmp(unit, "pt")) {
243 mDefaultFont.size = NSIntPointsToTwips(variableSize);
244 mDefaultFixedFont.size = NSIntPointsToTwips(fixedSize);
245 }
246 else {
247 float p2t;
248 GetScaledPixelsToTwips(&p2t);
249 mDefaultFont.size = NSFloatPixelsToTwips((float) variableSize, p2t);
250 mDefaultFixedFont.size = NSFloatPixelsToTwips((float) fixedSize, p2t);
251 }


It does change the mDefultFont.size and mDefaultFixedFont.size to the new value.
But somehow when the page got refresh, these two value is not been used. IF we
reload the page, it will get the updated value.
According to marc, this looks like a regression intrdouced in 5/30 by hyatt.
Reassign to hyatt. Change OS to all.

Comment 16

[Frank Tang]

somehow the font face have no problem, but only the font size. 

Comment 17

[[e-mail] (away - not reading bugmail)]

Ben,

I realize that this bug has morphed into something else than what you originally
reported. However, I had trouble reproducing the problem per your  description
on both Linux and W2K. ftang walked through the debugger with me and we verified
that layout is receiving the correct font sizes, which leads us to believe that
this is not an UI issue. The bug ftang reproduced is quite significant, but feel
free to refile the original issue, if you think it's valid and potentially
reproducible. Please also try a different machine if you can and include some
screenshots of the font pref panel.

BTW I used June 25 and July 16 trunk builds on Linux and May 5, June 1, June 26
and July 13 builds on W2K.

Comment 18

[David Hyatt]

The bug where font/color prefs aren't reflected until a reload is 90081.  Is
there really a separate issue here, or is this just a dup of 90081?

Comment 19

[Frank Tang]

similar to 90081.  
But it seems the color change part is fixed in 90081. The behavior is similar
for font in this bug. 

Comment 20

[Frank Tang]

I think the rule of reflow type is mess up. Is that ture changing of default
font should fire up a style change reflow. 

Comment 21

[David Hyatt]

I assume this is just a dup of 90081.

Comment 22

[David Hyatt]

Fixed by 90081.

Comment 23

[Yuying Long]

I checked it on today's (07-25) branch build, still got same result as Xianglan
and I got before - see comment of 2001-07-12 11:47:
Unicode, I can not see the font size change even I change size to like 72.  
And for western and some other fonts, I need do reload in order to see the
change, this is same as Frank's comment at 2001-07-16 11:34.

So, I re-open it.

Comment 24

[David Hyatt]

Is this a regression from my style landing?  I am not convinced.

Comment 25

[Yuying Long]

I'm not clear with when it start regression.  As we discuss before, it happened
sometime between 05-23 and 06-01.

But I just noticed bug 90081 has just been checked into trunk build.
So I installed a trunk build on Win2k-CN, seems the reload (for western) problem
has been resolved there, that's probably some place are really related to bug
90081.  However Unicode doesn't change the size follow by the setting in
Preferences is still existing.

Comment 26

[Ben Bucksch (:BenB)]

Filed bug 90474 about the priginal bug, which I still see.

Comment 27

[Ben Bucksch (:BenB)]

Filed bug 92416 about the original bug, which I still see.

Comment 28

[David Hyatt]

Still don't really understand this bug.  Everything works for me.

Comment 29

[Gervase Markham [:gerv]]

"Fixed font size" pref alters font size (as <PRE>) on Bugzilla bugs for me on
2001-08-15 Linux, but it has no effect on CSS font-family: monospace.

A good page to show the problem, which has some text in <PRE> and some styled,
is: http://www.meyerweb.com/eric/css/tests/css2/sec15-02-02.htm

rbs: is this touched by your pending fonts checkin?

Gerv

Comment 30

[kill this account]

On Yuying's system I saw that a reload was required after changing the font 
pref size before the displayed size changed but I cannot reproduce this 
bevavior on my system.

I do see that changing the monospace font size does not change the size of
elements where the CSS font spec is monospace.

The Unicode issue is separate issue and I recommend it not be considered part
of this bug. Font preferences (eg: size) are by language group. We first look 
for a language tag in the document, if none we look at the encoding. However,
since Unicode does not imply a language group if the document does not have a 
language tag we fallback to the user's locale and hence the size pref set in
the user's locale's language group. Mozilla does appear to do this.

Comment 31

[rbs]

So this whole issue is another -moz-fixed vs monospace... (see also bug 92416 
and bug 78517).

There is so much confusion around this -moz-fixed vs monospace that I am more
and more inclined that they should be exposed on the Fonts prefs dialog as I
alluded in bug 61883. Setting specific sizes for monospace and -moz-fixed
isn't possible at the moment (unless they are aliased to the same thing), but
that would be possible with my changes. Due to recurrent demands for the ability
to set specific sizes and the fact that other platforms might take a good while
to catch up with the internal machinery needed to support |font-size-adjust|, I
am considering allowing the non-spec way via a pref since my patch handles both
ways (the non-spec way is XP and doesn't involve doing some magic in the innards
of GFX).

Comment 32

[rbs]

The issues of this bug have been cornered with my recent font revamps.
Marking FIXED. Feel free to re-open if some weird things are still observed.

Comment 33

[Yuying Long]

I still can see this problem on 12-17 trunk build on WinXP and linux when  
change the font for Unicode. 

RE-open.

Comment 34

[rbs]

Care to document your steps to reproduce. Things work fine for me on Win2K.

Comment 35

[Yuying Long]

Steps:
1. Edit | Preferences | Appearance | Fonts.
2. Choose "Unicode" for language for fonts.
3. Change the size to a very large for both proportional and monospace, I used 48.
4. Click on OK and go like this mozilla bug report page.
5. View | Character Coding, choose unicode.

Result:
The page get reloaded, but the size can not be changed properly.

If I change the font size for western instead of unicode by same steps as above,
then I can see the changed font size. 
Seems it's no related with css though.

Comment 36

[rbs]

OK, the remainder, Unicode & UserDefined & perhaps others, are in the intl area. 
The updated value for "font.language.group" is not reflected in the presentation 
context when the pref is changed. I used the following break point in 
PreferenceChanged() and noticed that the language group is not read/updated by 
anybody.

void
nsPresContext::PreferenceChanged(const char* aPrefName)
{
if (!strcmp(aPrefName,"font.language.group")) NS_ASSERTION(0,"XXXrbs - break");
[...]
}

Notice also the comment in DeviceContextImpl::GetMetricsFor() where it is 
questioned why the language group is null sometimes. Although I am not sure, 
perhaps this may come from to the fact that the pref for "font.language.group" 
is not read by anybody [LXR search] when it is supposed to. Currently, default 
font attributes are ditacted by the document's charset, and by default, the 
charset is assumed to be x-western.

Comment 37

[Frank Tang]

It seems font pref not function well. mark it as nsbeta1+

Comment 38

[Frank Tang]

shanjian- can you take a look at this one ? Is this a problem in the font code
or ui code ?

Comment 39

[Shanjian Li]

Yuying,
As bstell mentioned in comment #30, unicode encoding is a little bit misleading.
If the page is encoded in one of the unicode coding scheme, we pickup the locale 
and treate its language group as the language group for current page. That's say 
unicode font setting is unused. Yes, this is a problem and we are planning to 
fix it. (My progress was blocked by a XML problem.) So this bug can be marked as 
fixed. 

Comment 40

[Yuying Long]

OK, followed by the comments above I'll mark it as verified.