243428 - Preference styling on OS X is broken

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[JongAm Park]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040512 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040512 Firefox/0.8.0+

Perference : Privacy & Advanced
================================
There is a + icon indicating that there are more sub items in an item.
On MacOS X with recent nightlies, the + is displayed as a blank aqua buttons.

P.S. Is new theme being prepared? or is it just broken?

Reproducible: Always
Steps to Reproduce:
1. Open preference and check privacy and advanced settings
2. check if + icons are being displayed as a blank buttons
3.

Actual Results:  
Blank buttons

Expected Results:  
+ icons

Comment 1

[Martin Creutziger [:MMx]]

I can confim this behavior with my MOZILLA_1_7_BRANCH builds since the 9. May. I
didn't do one on the 8., and on the 7. the world was still in good shape.
might that be related to mconnor's checkin on 2004-05-08?

Comment 2

[Martin Creutziger [:MMx]]

Attachment: Screenshot how it looks now

That's how it looks now.

Comment 3

[Martin Creutziger [:MMx]]

Attachment: Screenshot how it looked before

Thats how it looked using "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.7) Gecko/20040507 Firefox/0.8.0+ (MMx2000)"

Comment 4

[JongAm Park]

(In reply to comment #3)
> Created an attachment (id=148466)
> Screenshot how it looked before
> 
> Thats how it looked using "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
> en-US; rv:1.7) Gecko/20040507 Firefox/0.8.0+ (MMx2000)"

Thank you for the screen shot!

Do you know who changed this bug's status to "unconfirmed"?

Comment 5

[Martin Creutziger [:MMx]]

AFAIK it is unconfirmed until someone sets it to "NEW"

Comment 6

[Martin Creutziger [:MMx]]

not only the "+" icons are wrong, the whole dialog is messed up. The Icons on
the left, the borders, etc.

Comment 7

[Martin Creutziger [:MMx]]

Attachment: Screenshot how it looks now

Better screenshot, same dialog active as in the other attachment #148466 [details]

Comment 8

[Hiro]

It reproduced with the trunk version nightly build 5-13.

Comment 9

[Martin Creutziger [:MMx]]

This is a regression, isn't it?
Could the reporter or another empowered user set the keyword, please?

Comment 10

[JongAm Park]

(In reply to comment #9)
> This is a regression, isn't it?
> Could the reporter or another empowered user set the keyword, please?

Uh... What keyword can be good?

Comment 11

[Martin Creutziger [:MMx]]

well, "regression" would be nice. ;)

Comment 12

[Mike Connor [:mconnor]]

I don't THINK I touched anything that should do this, but it could be linked to 
the build process that sets up the mac skin.  Kevin, any idea on what 
could/might be causing this?

Comment 13

[Kevin Gerich]

Did some investigating and I think it's caused by Ben's theme manager checkin.
Specifically http://lxr.mozilla.org/mozilla/source/browser/base/skin/mac/jar.mn#36

This is what I see in my terminal when I make in browser/base

[mozilla/browser/base] kev% make
/usr/bin/make export
make[2]: Nothing to be done for `export'.
/usr/bin/make libs
+++ making chrome /Users/kev/MozillaSource/mozilla/browser/base/skin/mac  =>
../../../../dist/bin/chrome/classic.jar
+++ updating chrome ../../../../dist/bin/chrome/installed-chrome.txt
+++     skin,install,url,jar:resource:/chrome/classic.jar!/skin/classic/browser/
Use of uninitialized value in substitution (s///) at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 54, <JARFILE> line 36.
Use of uninitialized value in substitution (s///) at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 55, <JARFILE> line 36.
Use of uninitialized value in string eq at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 56, <JARFILE> line 36.
Use of uninitialized value in substitution (s///) at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 56, <JARFILE> line 36.
Use of uninitialized value in substitution (s///) at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 57, <JARFILE> line 36.
Use of uninitialized value in string eq at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 58, <JARFILE> line 36.
Use of uninitialized value in substitution (s///) at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 58, <JARFILE> line 36.
Use of uninitialized value in concatenation (.) or string at
/System/Library/Perl/5.8.1/File/Spec/Unix.pm line 59, <JARFILE> line 36.

ccing Ben

Comment 14

[Asaf Romano (gone)]

...and this also applies to the advanced section (and in any place this widget
is used).

Should be fixed before a the next release.

Comment 15

[Mike Connor [:mconnor]]

ben was going to look into this sometime this week, anyone want to build the 
aviary branch to properly test this? :)

Comment 16

[Martin Creutziger [:MMx]]

I have to admit that I don't know what a "aviary branch" is. 
I am building from the MOZILLA_1_7_BRANCH as often as interesting changes have
been made. So if there is a checkin related to this bug, I will build again. :)

Comment 17

[Joel Nelson (don't send email)]

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

Comment 18

[Joel Nelson (don't send email)]

I also noticed the icon styling in Preferences appears to have gone back to Qute from Pinstripe.

Comment 19

[Joel Nelson (don't send email)]

Present in both Firefox and Thunderbird.

Comment 20

[Martin Creutziger [:MMx]]

Could somebody please give me a pointer (explanation/URL) what this
AVIARY_1_0_20040515_BRANCH is?
I could build from that one, too, if I knew what it is...

Comment 21

[Martin Creutziger [:MMx]]

OK, now I know what this branch is. I built it this morning and have to say that
the whole branch seems br0ken somehow :( 
I hope it gets better soon...
Nevertheless, I will switch to building AVIARY-branch. At least as long as there
are no official nighties.
My nighties can be found here: (in case somebody wants to test them ;) )
http://firefox.kicks-ass.org/download/unofficial/nightly

Greetings . . . Martin

Comment 22

[jhp (no longer active)]

Works for 20040508 firefox nightly build, but broken the next day (20040509).

Comment 23

[JongAm Park]

Ah.. I donwnloaded Windows version (May. 19). It seems to have broken preference
styling. May. 19 version has lots of problems. 

Comment 24

[JongAm Park]

May 25 version still has broken styling.

Comment 25

[Hiro]

AVIARY_1_0_20040515_BRANCH and trunk are still reproduced. :-(

Mac OS X 10.3.4
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040528
Firefox/0.8.0+

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040527
Firefox/0.8.0+

Comment 26

[jhp (no longer active)]

It seems that the wrong pref.css is getting packaged.  In classic.jar, we are getting the file from 
browser/components/prefwindow/skin/pref.css rather than browser/base/skin/mac/pref.css.  If I 
manually add browser/base/skin/mac/pref.css to classic.jar in a nightly build, then the problem goes 
away.  No idea yet why we are getting the wrong file.

Comment 27

[jhp (no longer active)]

The files Bookmarks-toolbar.png, BookmarksManager.css, Options.png, and pref.css are stored in 
classic.jar in the browser/base/skin/mac directory, but are overwritten with non-Mac specific versions 
in browser/components/bookmarks/skin and browser/components/prefwindow/skin.

Comment 28

[jhp (no longer active)]

Nothing changed in the build system on the date that this issue appeared.  The
only thing I can think of is that since all four files that I mentioned above
were changed on 2004-05-08, they have later dates than the mac specific files
and make-jars.pl chooses to take these "newer" files to overwrite the mac files.

So it seems that the build has always been somewhat broken.  I think that the
pinstripe building should come last, so that it can overwrite all the generic files.

Comment 29

[jhp (no longer active)]

Attachment: possible patch

Ugly, but it works.

Comment 30

[jhp (no longer active)]

Another bug in the build system is that the rsync step (creates the .app bundle)
should be the last thing run in the build.  The Firefox build goes on to build
the extensions directory after the rsync step.

Comment 31

[jhp (no longer active)]

Attachment: better patch

This patch puts the browser/app directory last, so that rsync is the last thing
that is run in the Firefox build.

However, I am still seeing the problem where make-jars.pl will not overwrite
the files since those files in browser/components/prefwindow have a later CVS
checkout date than those in browser/base/skin/mac.  Is there any way to specify
to make-jars.pl that some files should always overwrite a preexisting file in a
jar, no matter what the date?

Comment 32

[Mike Connor [:mconnor]]

what we really need to do is to make packaging of the skin an either/or
function, if we're building on mac, we shouldn't be building qute and then
building pinstripe, we should just build pinstripe.

Comment 33

[Ben Goodger (use ben at mozilla dot org for email)]

This is unrelated to the errors you're seeing, which are nonfatal and I think
related to the theme icon. 

This is a problem relating to the fact that the Windows theme files seem to be
being built on OS X for some reason (not exactly sure why) and then the Mac
files are being built later, and are not replacing the Windows files because the
Windows files (as of Arvid's latest update) have a newer mtime. 

The standard mechanism for dealing with this problem is to prefix the lines of
the affected files in jar.mn with '+'... This forces the files to overwrite any
existing files. 

Ultimately I think the solution to the problem that caused this is a clean
separation of the theme directories. 

Comment 34

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

Ensure the Mac preferences theme stuff overwrites any existing matter.

Comment 35

[Ben Goodger (use ben at mozilla dot org for email)]

Fixed branch and trunk. 

Comment 36

[Hiro]

(In reply to comment #34)
> Created an attachment (id=149653)
> patch
> 
> Ensure the Mac preferences theme stuff overwrites any existing matter. 

It still reproduces.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040531
Firefox/0.8.0+

Comment 37

[Asaf Romano (gone)]

I tried last nightly and it is still very reproduces :-\

Comment 38

[Mike Connor [:mconnor]]

the last nightly would have been built before this was checked in.  However,
this likely doesn't fix the bookmarks manager, if that's indeed broken.

Comment 39

[jhp (no longer active)]

(In reply to comment #33)
As I mentioned in comment #28, the Mac pinstripe theme is actually built first,
and then overwritten by the Qute theme files.  So your change will have no
effect, unless it is merged with my change, which puts the pinstripe theme
building at the end.

Comment 40

[Ben Goodger (use ben at mozilla dot org for email)]

What I'm confused about is why Qute is being built at all on Mac. Pinstripe is
completely independent and shares nothing with it.

Comment 41

[jhp (no longer active)]

Sorry, I may have misspoken.  Qute itself (in browser/base/skin) is not getting
built.  However, the theme files in browser/components/bookmarks/skin and
browser/components/prefwindow/skin (and possibly other directories) are getting
built.  Four of the files in these two directories are duplicates of files in
browser/base/skin/mac, and are overwriting the mac files.

Comment 42

[Ben Goodger (use ben at mozilla dot org for email)]

Ah. I see now, thanks Javier. 

I have shall we say an "interesting" fix for this bug coming in the next week. 

Comment 43

[Ben Goodger (use ben at mozilla dot org for email)]

This looks fixed to me now, branch only. Will be fixed trunk after theme
restructuring lands there this week. 

Comment 44

[Martin Creutziger [:MMx]]

Well, in my AVIARY build, checked out last night (2004-06-07, 00:15UTC), it is
still broken.
When did you check in the patch? I haven't found anything yet.

Comment 45

[Hiro]

This problem was fixing by Firefox which built by AVIARY BRANCH today.

Mac OS X 10.3.4
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040607
Firefox/0.8.0+

Comment 46

[Martin Creutziger [:MMx]]

This seems to be fixed now, isn't it?
(both on trunk *and* branch)

Comment 47

[JongAm Park]

(In reply to comment #46)
> This seems to be fixed now, isn't it?
> (both on trunk *and* branch)

Yes. It is fixed.
However.. On Preference->Downloads->FileTypes list, no icon is displayed
as it does with the Windows version. Maybe it is different issue, though.

Comment 48

[Martin Creutziger [:MMx]]

(In reply to comment #47)

> However.. On Preference->Downloads->FileTypes list, no icon is displayed
> as it does with the Windows version. Maybe it is different issue, though.

This seems to be fixed on trunk, too. I can see the icons with a trunk nighty:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040726
Firefox/0.9.1+

It is *not* fixed on the AVIARY branch, but I guess it is a different issue.
Maybe  a bug exists already.

Comment 49

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change