191887 - [zip builds] default theme (skin) is Modern instead of Classic

Status: VERIFIED FIXED

(Core Graveyard :: Skinability, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I thought there was a bug on this in the past, but apparently there isn't, or at
least I can't find it.

Since early in 1.3, the default theme on Mozilla unix builds has been Modern.  I
remember being told that this was accidental fallout from bryner's change to
remove the chrome for XBL form controls.  (Why is the default theme so fragile?)

(Furthermore, when upgrading to a new 1.3 version from an old Mozilla, with the
default theme set to something that's no longer available, the default is not a
good version of modern, but a horribly messed up version of Modern, even with my
fix to bug 144027.)

(Is the default still Classic on Windows and Mac builds?)

Comment 1

[timeless]

profile manager in mozilla win32 nightlies is still classic. i'll look for the
bug about this...

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Actually, the change for the case of using an installation where the default is
a non-present theme exists cross-platform.  (I tried Windows, anyway, and the
problem exists there too.)  I suspect that problem might hit a bunch of users
(as bug 144027 has, in particular because running on a third version causes a
messed up skin.

In particular, the problem that is reproducable across platforms (due to the
change in default, I think) is the following:
 1. install an instance of 1.0.2, 1.2.1, and current trunk
 2. Create a profile using 1.0.2, and install LittleMozilla from
http://themes.mozdev.org/themes/littlemozilla.html using the link
javascript:doXPIInstall('http://mozdev.mirrors.nyphp.org/themes/themes/littlemozilla_10.xpi');
 3. Switch that profile to LittleMozilla
 4. Start that build, so it uses the LittleMozilla theme.

Path A:
 5. Run with that profile in 1.2.1.
     [ Result: Classic ]
 6. Run with that profile in current trunk.
     [ Result: Clodern ]

Path B:
 5. Run with that profile in current trunk.
     [ Result: Modern ]
 6. Run with that profile in 1.2.1.
     [ Result: Clodern (but a different variety) ]

Path A is a realistic path that users who see bug 144027 are likely to see.

(Note that I've done Path A and Path B on Windows, but only Path A on Linux.)

Also note that I'm testing zip builds, not installer builds.  However, I suspect
that affects only the initial install, and not the stuff in this comment.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Actually, it's not Linux/Unix-specific, it's zip build specific.  The default in
the Windows zip build is actually a mix of modern and classic.  (In 1.2.1 it was
classic.)

Comment 4

[Andreas Kunz]

dbaron, did you mean bug 180984 (or bug 179651, duped)?
One is only on Linux, the other one supposed to be fixed... but maybe still
worth reading.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Some investigation, with dveditz's help, has led to the theory that the select
line needs to be later, since it will only do anything to chrome that has
already been registered.  (When installed-chrome.txt is processed a second time,
the chrome after the select will already have been registered the first time
through.)

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I've confirmed that moving the select line lower as if it were generated after
going through the themes subdirectories fixes the problem for me in the build
where I can still reproduce it repeatably.

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch

This fixes the order of the installed-chrome.txt so that it's generated in the
order that I confirmed fixes the problem in the build where I can still
reproduce the problem (which is a different tree, but anyway...).

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Taking.

Comment 9

[hacker formerly known as [e-mail]]

Comment on attachment 113522 [details] [diff] [review]
patch

It's not immediately obvious why putting a dependency upon the directory would
fix the ordering problem.  The directory will always exist, correct?  The
timestamp on the directory shouldn't change as there's no files generated in
that directory (other than the Makefile).  Also, we should fix that echo so
that we don't end up with that select line 20 times in our local builds.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I'd hope that it's depending on the phony target and not the directory itself. 
That's what seems to be happening, since it does fix the ordering.  (Hopefully
it's portable, anyway.)

Any other suggestions on how to fix it?  (Should we just move it to xpfe/bootstrap?)

(And any suggestions on fixing the echo?  It isn't really much of a problem...)

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch

Does this make more sense?

Comment 12

[hacker formerly known as [e-mail]]

Comment on attachment 113538 [details] [diff] [review]
patch

This might cause problems for other gecko xul apps (ie phoenix) but wfm.

Comment 13

[Brian Ryner (not reading)]

http://bugs.gnu.org/cgi-bin/gnatsweb.pl?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=1476

details a bug with parallel execution of double-colon rules that's present in
make versions prior to 3.79, which both dbaron and the nightly build machine are
using.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 113538 [details] [diff] [review]
patch

sr=dveditz

Comment 15

[Brian Ryner (not reading)]

Comment on attachment 113538 [details] [diff] [review]
patch

I don't really like this.  It will cause the same thing to have to be
duplicated for phoenix and may cause problems for --disable-xul in the future. 
I'd like to focus on the apparent make bug instead.

Comment 16

[Daniel (Leaf) Nunes]

I just updated make on bawb (trunk's build system) from redhat 7.1's make 3.79.1
src rpm. If this problem is related to a bug in make 3.78, you should know from
tomrrow's builds.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I spun off bug 191954 and bug 191957 on the issues raised in comment 2.

Comment 18

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Fixed by build machine upgrade.

Comment 19

[Grace Bush]

verified 4/22 builds