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

VERIFIED FIXED

Status

SeaMonkey
Themes
--
critical
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: Roland Mainz, Assigned: Joe Hewitt (gone))

Tracking

({regression})

Trunk
Sun
Solaris
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 74551 [details]
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...
(Reporter)

Comment 2

16 years ago
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).
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?
Keywords: regression
Could this be related to the REGCHROME changes that went in recently?

Copying seawood.
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.
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
So much for plausible deniability. :-P  Where's this silly embed-sample....
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

16 years ago
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?
Fixed by checkin for bug 131016
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 11

16 years ago
verified (commercial netscape build: 2002-03-26-05-TRUNK)
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.