131461 - Build starts with "modern" skin instead if "classic"

Status: VERIFIED FIXED

(SeaMonkey :: Themes, defect)

Description

[Roland Mainz]

2002-03-15-08-trunk build on Solaris/SPARC.

All previous builds started with the "classic" skin - until this one.
Unfortunately the "modern" skin does not work well with 8bit visuals -
screenshot follows.

Suggested fix:
Switch back to "classic" skin by default.

Comment 1

[Roland Mainz]

Attachment: Screenshot from 2002-03-15-08-trunk on a 8bit only framebuffer

This is a major hit for most older SunS/APRC machines... this issue is close to
a SMOKETEST blocker...

Comment 2

[Roland Mainz]

BTW: The above screenshot is shows a still useable Zilla (but it is ugly) - but
on machines where most palette colors are used by other applications you get a
Zilla with black menu backgrounds and black text (classic skin is still useable
even useable in this case).

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is a recent regression.  The profile manager has been coming up with
"modern" theme for two days now as well.  The default Mozilla theme should be
classic, no?

Comment 4

[u46933]

Could this be related to the REGCHROME changes that went in recently?

Copying seawood.

Comment 5

[hacker formerly known as [e-mail]]

It could be but those changes went in almost a week ago (last Wednesday).  I'd
be very surprised if those changes alone triggered the theme change.

Comment 6

[u46933]

It happened between March 13 at 4PM and March 14 at 8 AM.

seawood checkin for 129456 did occur during this time.

The problem is definitely installed-chrome.txt, because if I take the 
installed-chrome.txt from March 13 at 4 and put it on Mar 14 at 8AM, it works.

The actual problem is this line:

skin,install,url,jar:resource:/chrome/embed-sample.jar!/skin/classic/embed/

It should be:

skin,install,url,jar:resource:/chrome/embed-sample.jar!/skin/modern/embed/

This fixes the problem. I really don't know why

Comment 7

[hacker formerly known as [e-mail]]

So much for plausible deniability. :-P  Where's this silly embed-sample....

Comment 8

[hacker formerly known as [e-mail]]

Ok, so here's the problem....in the Makefile.in, we were explicitly registering
'skin modern/embed embed-sample.jar'.  Now the jar.mn is auto registering '	skin/classic/embed/contents.rdf	
(skin/contents.rdf)' .  That explains the difference that mkaply is seeing.  I
don't understand why it makes a difference though.  If anything, the
registration looks backwards.   If you register the classic skin, it should use
the classic skin by default, no?

Comment 9

[Mike Kaply [:mkaply]]

Interesting.

Even though the jar.mn says classic skin/classic/embed/contents.rdf, if you look 
at:

http://lxr.mozilla.org/seamonkey/source/embedding/browser/chrome/skin/contents.r
df

which is the contents.rdf that is actually referenced, it says modern 
everywhere.

my guess is that the mismatch is what is actually causing the problem. I'm at 
home so I can't verify this right now.

Should embed-sample be registered at all given that none of the chrome in it are 
actually needed by the browser?

Comment 10

[hacker formerly known as [e-mail]]

Fixed by checkin for bug 131016

Comment 11

[Patty Mac]

verified (commercial netscape build: 2002-03-26-05-TRUNK)