181487 - TTF UI font weirdness after 2002111404 nightly build

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Tom]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3a) Gecko/20021122
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3a) Gecko/20021122

On nightlies after the 2002111404 build AA (anti-aliased) fonts are disabled
when the browser starts for the first time after installation (example1.png).
Opening the font preferences dialog (example2.png) does not show the fonts I've
selected and the AA fonts are missing from the font list. Restart Mozilla
(example3.png) and everything is rendered AA including the menubars. Open the
font preferences dialog (example4.png) and the correct fonts appear. Open a new
window (Ctrl+N) (example5.png) and the menubar fonts are no longer rendered AA.

Reproducible: Always

Steps to Reproduce:
1. Install mozilla nightly (after 2002111404 nightly build)
2. Close browser
3. Restart browser
Actual Results:  
No AA fonts on first invocation. Restart browser. Fist window that opens has AA
menubar fonts. Succeeding windows' menubar fonts are not anti-aliased.

Expected Results:  
AA fonts when browser initially starts and consistent behavior with menubar fonts.

Comment 1

[Tom]

Attachment: Initial startup window

Comment 2

[Tom]

Attachment: Initial startup font prefs

Comment 3

[Tom]

Attachment: Second startup first window

Comment 4

[Tom]

Attachment: Second startup font prefs

Comment 5

[Tom]

Attachment: New window opened after second startup

Comment 6

[Andrew Schultz]

are you using an xft build?  the standard builds don't do anti-aliasing by
default.  do you see this behavior with a clean profile?

Comment 7

[Tom]

Attachment: my ~/.mozilla/user/foo/user.js

I'm using standard builds with anti-aliasing enabled via the attached user.js
which I've created and placed in my ~/.mozilla/user/foo/ directory (the same
one that contains prefs.js etc.). I get the same behavior with a clean profile.

Comment 8

[Tom]

Correction: make that "I get the same behavior with a clean profile after I've
added the attached user.js." Obviously a standard build with a clean profile
won't anti-alias.

Comment 9

[Andrew Schultz]

worksforme with linux trunk build 20021123.

the difference between your user.js and the defaults is that TrueType fonts are
turned on.  but I don't know why that would change the font used by Mozilla's UI.

Comment 10

[Kai Lahmann (is there, where MNG is)]

does this problem still exist?

Comment 11

[Tom]

Yes, I still have the problem.

My workaround is to:

1. After installing a new nightly, when the profile selection dialog comes up I
select "exit" instead of "start".

2. I then start up mozilla in the usual manner.

3. After the main window comes up (which has AA fonts on the menubar), I Ctrl-N
a new one (which does not have AA fonts on the menubar) and close the first one. 
All new windows from then on (until mozilla is restarted) don't have AA fonts on
the menubar (which is my preference).

Comment 12

[Asa Dotzler [:asa]]

I'm not seeing any wierdness with 1.6 or the latest nightly build. Please reopen
if you can reproduce with the latest build. Thanks.

Comment 13

[Tom]

(In reply to comment #12)
> I'm not seeing any wierdness with 1.6 or the latest nightly build. Please reopen
> if you can reproduce with the latest build. Thanks.

The only weirdness I continue to see is that after using Mozilla Installer to
install a new nightly, when the Mozilla Profile Manager comes up after the
"Installation Complete" window, if I click on the "Start Mozilla" button Mozilla
starts with AA disabled. The workaround has been simple for some time now (for
me) - click "Exit" on the "Mozilla Profile Manager" window and then click on my
toolbar icon which simply runs /usr/local/mozilla/mozilla where I keep my latest
nightlies. Mozilla then comes up (and will continue to do so) with AA enabled.

One aspect of this bug - where the menubar fonts on the first browser window
would be rendered AA but successive windows (invoked via "File -> New ->
Navigator Window") would not have their menubar fonts rendered AA - finally went
away about two weeks ago when I upgraded the version of GTK that I was using,
leading me to believe that this particular problem was a GTK bug all along.

I'm reopening this because I still see the aforementioned weirdness with the
latest (2004020308) build, but if you can't reproduce it then close it because
it has an easy workaround for me and is most likely unique to my configuration
(a crufty old Debian box, apt-get upgraded countless times).

Comment 14

[Asa Dotzler [:asa]]

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

Comment 15

[Andrew Schultz]

> The only weirdness I continue to see is that after using Mozilla Installer to
> install a new nightly, when the Mozilla Profile Manager comes up after the
> "Installation Complete" window, if I click on the "Start Mozilla" button Mozilla
> starts with AA disabled.

Actually, the installer would start Mozilla as the user who ran the installer
(root), so it has a different profile without your AA settings.  When you quit
or just hit cancel in the profile manager and then start up normally, you get
your profile with your AA settings.

Since 1.7, the installer does not start up Mozilla when it's done.
resolving WORKSFORME

Comment 16

[Tom]

> Actually, the installer would start Mozilla as the user who ran the installer
> (root), so it has a different profile without your AA settings.

I always install the nightlies using my user account (which I gave /usr/local
privileges on my box - not really kosher now that I think about it) so that
wasn't the problem for me. Nonetheless, this bug went away when the installer
lost the option of launching Mozilla.