206482 - Modern status bar and Mail/News caption text is small

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[Mark Anderson]

Sometime since I last built my tree (2-3 weeks ago?), something changed that
caused Modern to have a shorter status bar with smaller text.  This also made
the text under the Mail/News buttons really small.  It seems to be linked to the
MessageBox text settings in the Display control panel in Windows.  However, so
too is the text on the other toolbars, so increasing the size is not an option
(the other text gets huge).  Was this a design decision to make that text
smaller?  If not, I wouldn't mind being able to read it.... ;)

Comment 1

[snebeling]

Attachment: Screenshot (IE status bar vs. Mozilla 1.4rc1 status bar)

Yep, the font size has become too tiny.
On Windows, the standard text size for status bars should be used.
Or at least revert it to the one used in 1.3.

Comment 2

[rbs]

Attachment: modern skin: computed style data reported by the DOM inspector

Comment 3

[rbs]

Attachment: classic skin: computed style data reported by the DOM inspector

The DOM inspector is reporting different font-size values.

(BTW, it is rather curious that it reports an empty font-family.)

Comment 4

[rbs]

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

Comment 5

[Felix Miata]

Attachment: screenshot 1.4rc2 1024x768 96DPI W32

Status bar size looks fine to me. Seems as though the size DOM inspector
reports is inaccurate.

Comment 6

[Dan Soper]

I'm seeing a much-too-small font size with Mozilla/5.0 (Windows; U; Win98;
en-US; rv:1.4) Gecko/20030624

It was fine with 1.3.1; why the change?

Comment 7

[Felix Miata]

What skin? What resolution? What DPI? Are these three unchanged since upgrading
1.3.1 to 1.4? Does yours look like any of the attached screenshots?

Comment 8

[Dan Soper]

Attachment: another screen grab

Modern skin
1280 by 1024 resolution @ 96dpi.

Not changed since 1.3.1 - if I had changed any of those things, I would've
switched back before coming to bugzilla.

What I@m seeing is exactly as described: the font size of the status bar text
is far too small. I'm attaching a screen capture of my own.

Comment 9

[Mark Anderson]

The newest screenshot is exactly what I see (well, my font is not the same one,
but the size is the same).

The captions for the mail/news buttons are in the same font as the status bar at
the same size, too.

WinXP, 1024x768, 96 dpi.  Unchanged since 1.3.

However, I am running with Large Fonts in Windows (120 dpi).  Is Mozilla
possibly scaling from this somehow?

Comment 10

[Felix Miata]

Attachment: W98 screenshot group showing DPI effects

Those using resolutions higher than 800x600 with the Win system default
"small", which is 96 DPI, can expect controls fonts to be small. Up the DPI and
your status bar text size should increase, along with the menu text.

Note in this screenshot that the status bar size is the same in both 120DPI and
144DPI, while in 96DPI it is considerably smaller. This is probably because the
fonts used come in point sizes, a coarser granularity than pixel sizes, and the
actual size called for in the status bar is coming up the low edge case in one
and the high edge case in the other.

Dan Soper's font looks like both 1-the next pt increment smaller, and 2-a serif
font which, like most serif fonts, is smaller than typical same nominal sized
sans-serif fonts.

Since I'm seeing larger text than complained of here, I suspect these upgrades
may not have been made into empty directories as directed in previous release
notes. The current release notes misplace the uninstall the old version first
directive in the Linux section, but it actually applies to all versions.

Another possible fix is to delete the .mfl file from the profile directory.
Testing with a fresh new profile would also be prudent.

Comment 11

[Dan Soper]

I uninstalled Moz1.3.1 before installing 1.4.

Comment 12

[snebeling]

I too still see the problem in 1.4final, using the following config:

- Windows XP
- 800x600, standard Windows font size, standard Mozilla font size
- Clean Moz install
- Fresh profile
- Modern Theme (Classic Theme works, though)

Comment 13

[snebeling]

Okay, a bit further...

I'm not familiar with the Mozilla chrome and styling system,
but in the archive file

  mozilla.org\Mozilla\chrome\modern.jar

there is a file called

  skin\modern\global\global.css

In that CSS file, the following lines can be found:

/* ::::: statusbar ::::: */

statusbar {
  border-top: 1px solid #C7D0D9;
  min-width: 1px; /* DON'T DELETE!
    Prevents hiding of scrollbars in browser when window is made smaller.*/
  background-color: #C7D0D9;
  color: #22262F;
  font-size: smaller;
}

I don't know who put the "font-size: smaller;" declaration in there,
but if that line is removed, the bug goes away.

(In classic.jar's global.css the line is missing, explaining why
 the Classic Theme is unaffected by all this.)

Comment 14

[Felix Miata]

In http://bugzilla.mozilla.org/attachment.cgi?id=126942&action=view the left
center is what I use, which if anything, is larger than I'd like, not smaller.
In OS/2 @ same resolution and DPI, status bar is a size smaller than in W32, and
just right for me.

Comment 15

[Mark Anderson]

I wish mozilla.org archived more nightlies than it does....  Anyway, this is
*not* present in 1.4b (dated 2003-05-07), but it *is* present in 1.4rc1 (dated
2003-05-29).

I will do some bonsai investigating between those dates....

Comment 16

[Mark Anderson]

I would bet dollars to donuts that this is due to bug 72164.  Hence why removing
the "font-size: smaller" "fixes" this: it didn't do much of anything before. 
Cc:ing Eric Lawrence, who wrote that patch.

Comment 17

[Paul Antonucci]

Tried the suggested work around. It did enlarge the text in question but made
other things too big too, ie, address box was way too big.

>>>>in the archive file   mozilla.org\Mozilla\chrome\modern.jar

there is a file called    skin\modern\global\global.css

In that CSS file, the following lines can be found:

/* ::::: statusbar ::::: */

statusbar {
  border-top: 1px solid #C7D0D9;
  min-width: 1px; /* DON'T DELETE!
    Prevents hiding of scrollbars in browser when window is made smaller.*/
  background-color: #C7D0D9;
  color: #22262F;
  font-size: smaller;
}
I don't know who put the "font-size: smaller;" declaration in there,
but if that line is removed, the bug goes away.
(In classic.jar's global.css the line is missing, explaining why
 the Classic Theme is unaffected by all this.)

Comment 18

[Felix Miata]

For anyone who wants an improvement without waiting for a fix from Mozilla, and
don't want to change your DPI, you can perform the modification discussed in
comment 13, or a similar one. Instead of removing the line entirely, simply
change the word 'smaller' to 'small', or even 'medium' if you really want it
bigger. 'Smaller' typically means a bit over 80%, so you could substitute '90%'
for 'smaller' for a more modest size increase. Any of the preceding are probably
the better if you have multiple profiles. Otherwise, or if un- and re-jarring
modern.jar to edit is to complicated for you, it's simpler to add one of the
following lines  to chrome/userChrome.css:

     statusbar {font-size: small !important;}
     statusbar {font-size: inherit !important;}
     statusbar {font-size: medium !important;}
     statusbar {font-size: 89% !important;}

The same procedures can be applied to mailnews menu text if someone more
industrious than me wants to look up the correct rule in the appropriate jar.
According to DOM inspector, the selector for chrome/userChrome.css is
.toolbarbutton-1, which applies to browser button text as well.

Comment 19

[Eric Lawrence]

Mark, you are probably right.  Sorry to cause trouble, but the patch for bug
72164 was meant to fix issues with 'font-size: smaller' giving inconsistent
results across different DPI settings.  Evidently, it is exposing a problem with
the Modern theme.  For my settings, the window font size is one of the problem
font sizes for which 'font-size: smaller' had little or no effect (see bug 201811). 

I see this bug on OS X at 96 DPI and 16px default font size, although I would
not have noticed it because I usually have a minimum font size setting.  

Comment 20

[Felix Miata]

Should this be marked depends on bug 201811?

Comment 21

[Felix Miata]

Attachment: screenshot W2K 1.2.1 vs 1.4

1-As a general rule, statusbar fonts are smaller in 1.4 than in 1.2.1. 

2-The choice of user default font impacts statusbar size, and the smallest
result is at the default user default of 16px.

3-userContent.css rule 'statusbar {font-size: smaller !important;}' is of no
effect, since that is the default rule. It is mainly there as a label to
distinguish it from alternate rules.

Comment 22

[Felix Miata]

Attachment: screenshot W98 1.3.1 vs 1.4

1-At 96 and 120 DPI, choice of user default size does not impact size of
statusbar text.

2-Statusbar text is larger at 120 DPI than at 96 DPI, while identical to 120
DPI at 144 DPI.

3-DOM inspector reports various values for same sized statusbar text.

Comment 23

[Felix Miata]

Attachment: screenshot Mandrake Linux 9.0 KDE 3 with normal GTK1 1.4 release

1-User choice of default font size has no effect on statusbar text size.

Comment 24

[Felix Miata]

Attachment: screenshot Mandrake Linux 9.0 KDE 3 with GTK2 1.4 build with patch for bug 187256 applied

1-User choice of default font size has no effect on statusbar text size.

2-Statusbar text is larger than in GTK1 release build.

Comment 25

[Felix Miata]

Attachment: screenshot Mandrake Linux 9.0 KDE 3 comparing GTK1 to GTK2

1-Statusbar text is larger in GTK2.

2-Choice of user default size does not impact size of statusbar text.

Comment 26

[Felix Miata]

Attachment: screenshot comparing 1.4 @ 96 DPI in Linux and W32

1-Order of increasing sizes: W2K (smallest), GTK1, W98, GTK2 (largest). Quite a
range from smallest to largest.

Comment 27

[Felix Miata]

Attachment: screenshot comparing 1.4 @ 120 DPI in Linux and W32

1-Unlike at 96 DPI, GTK1 is smaller than W2K, while GTK2 remains the largest.

Comment 28

[Felix Miata]

Attachment: screenshot comparing 1.4 @ 144 and 192 DPI in W2K and W98

1-W2K in every case here is larger than W98.

Comment 29

[Felix Miata]

Attachment: screenshot - 1.2.1 on W2K vs. 1.3.1 on W98. 96, 120 & 144 DPI

1-They didn't match then either.

Comment 30

[Felix Miata]

Attachment: screenshot - 1.4 - W2K vs. W98. 96, 120 & 144 DPI

1-Computed statusbar font size reported by DOM inspector is shown, but don't
believe it. For every pair, the reported value is the same, yet it is quite
obvious that both cannot be correct.

Comment 31

[Felix Miata]

Attachment: screenshot - 1.4 on W98 @ 96 DPI with alternate css rules applied through userChrome.css

1-The alternate rules don't actually do anything.
60%=70%=80%=90%=100%=smaller=~10px.

Comment 32

[Felix Miata]

Attachment: screenshot - 1.4 on W98 @ 120 DPI with alternate css rules applied through userChrome.css

1-The alternate rules don't actually do anything.
60%=70%=80%=90%=100%=smaller=~12px.

Comment 33

[Felix Miata]

Attachment: screenshot - 1.4 on W98 @ 144 DPI with alternate css rules applied through userChrome.css

1-Unlike at the lower DPI settings, the alternate rules do actually have an
impact here.

Comment 34

[Felix Miata]

Attachment: screenshot - 1.4 on W98 @ 192 DPI with alternate css rules applied through userChrome.css

1-Statusbar text size is larger if 20px default is selected instead of 24px
default, though the latter is likely better suited for use at extremely high
resolutions. 24px at 1600x1200 corresponds to approximately the same onscreen
height on any given size monitor as does the default default 16px at 1024x768.
At 20px default, statusbar text is approximately css font-size: 95% wrt the
user default. At 24px default, statusbar text is approximately css font-size:
80% wrt the user default.

This is the last screenshot of this group.

Comment 35

[Eric Lawrence]

comment 20: Bug 201811 should have been fixed by bug 72164 (it fixes the problem
on OS X), but is still open pending verification that it's also fixed on an xft
build.  It is unlikely but possible that freetype was the culprit in that case.
 This probably shouldn't be marked as dependent on it.

Comment 36

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 37

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420