57.12 KB, image/gif
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.
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...
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?
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?
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
verified (commercial netscape build: 2002-03-26-05-TRUNK)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.