Closed Bug 101968 (clodern) Opened 24 years ago Closed 17 years ago

using profile across moz and netscape 6/7 results in "clodern" and "modassic" skins

Categories

(Core Graveyard :: Skinability, defect)

Product:
Core Graveyard
Component:
Skinability
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.4alpha

People

(Reporter: andreww, Assigned: shliang)

References

Details

Attachments

(4 files)

mod-assic skin screen shot
49.27 KB, image/gif
Details
the famous clodern skin.
45.26 KB, image/gif
Details
screen shot of mozilla profile using trunk build
21.72 KB, image/jpeg
Details
Screenshot of clodern NS7 (deinstalled) vs. 1.4RC1 (with bad 1.4Beta langpack, please ignore)
40.15 KB, image/jpeg
Details
Using today's trunk builds. Steps to reproduce: 1) start with a fresh mozilla trunk build and create a new profile. 2) launch mozilla with that profile. You should see classic skin 3) quit mozilla 4) launch netscape 6 trunk build 5) choose that same profile you just created in mozilla 6) resulting browser theme is an insane mix of classic skin with modern buttons. (see screen shot) alternative: 1) start with netscape 6 builds and repeat steps above, only create the profile in netscape 6 and then quit and try to open it in mozilla. See screen shots. Please do not mark this as just a netscape 6 problem. It appears to be a problem for both mozilla and netscape 6 which points to some common problem between them, and suggests the fix will be in the mozilla tree.
adding some folks to cc
I normally run commercial release builds for dogfood, using modern skin, and until a few months ago my moz debug builds also showed modern skin. Now they show clodern. It looks pretty bad. I haven't seen modassic (guess I must have formed this profile with a netscape build). Why don't moz and netscape use the same skin?
Toydern looks especially bad! I seem to have recovered by deleting all chrome-related files in the profile. This apparently won't affect typical end users directly, but I think it could impair our ability to spot other problems that will. I think it merits fixing.
"Don't do that"
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Sorry, most people's jobs here require them to "do that". You can decide what priority to give it, or punt to someone else, but it isn't invalid if it happens in the normal course of work.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
chrome registry.
Assignee: ben → hyatt
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Keywords: nsbeta1
I've received external user feedback on this one. Would love to see it fixed for the next release.
->hewitt as hyatt is on sabbatical, and may not be working quite as much ;-)
Assignee: hyatt → hewitt
Status: ASSIGNED → NEW
Nav triage team: nsbeta1+, adt2 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 rtm]
The problem here is that the file chrome.rdf in profiles contains information about the selectedSkin on a per-package basis. When you start a new profile and then shutdown immediately, the selectedSkin is only set for the navigator and chatzilla packages. This is because on startup, the only skins loaded are from the navigator, chatzilla, global, and communicator packages, and there is a check in the chrome reg that prevents writing the selectedSkin to chrome.rdf for global and communicator in the "default" case. However, on a skin switch these packages all will have selectedSkin set explicitly for them. So, when you start up the Netscape, you'll get the navigator and chatzilla skin parts from classic and everyting else from Modern. To fix this, we need to explicitly set the selectedSkin for ALL known packages for that skin. Looking into a way to do this.
This bug is extremely PAINFUL to fix. For some reason, most mozilla builds come with a chrome.rdf that is horked up - it only has selectedSkin set for global and communicator. This causes your profile chrome.rdf to get selectedSkin written to it as classic for all other packages (navigator, messenger, etc...) Thus, when you launch Netscape7 with the same profile, it sees that navigator uses the classic skin, and everything else default to modern, so you get clodern. trunk builds I've tested come with a chrome.rdf that has selectedSkin set for all packages - seemingly because their installed-chrome.txt has the install,select for classic. I don't know what's wrong with the branch. Solving this would mean we'd need some nasty hack in the chrome registry to make sure we use the same skin for navigator/messenger/editor as global/communicator. I am of the opinion that we should NOT hack this in. I really doubt this will affect many end users - it is only going to affect the tiny crowd of browser fanatics that install mozilla AND netscape 7 and play with them both regularly. We can rest assured that in the future, people who install mozilla builds will not see this problem, as current trunk builds will be ok.
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt2 rtm]
Is there any workaround to this?
Yes, the workaround is to switch skins and restart the application.
mcafee reported a similar problem. cc'ing him. mcafee, can you see if switching themes will help in this case? Want to make sure this is the problem you are experiencing. If not, have to investigate further. Thank you.
conrad, i vaguely recall some discussion about keeping mozilla, netscape and other embedded app profiles separate from each other... is there a bug filed which covers that?
mid-air collision, forgot to complete my thoughts in comment 18: a fix which keeps profiles for different products separate could help avoid issues like this bug.
lchiang: yes, switching themes fixes the problem.
Clarifying: once I switch themes, either classic or modern theme looks fine.
I'm wondering if there is not a high-level fix to this, like always double-selecting the skin when run for the first time (we do lots of one-time stuff for activation, and this seems to affect the branding aspect of commercial products). Another thing, rather than firewalling profiles to versions or product builds (which is probably debated elsewhere...) would be to pref-ing the skin selection to a version pref (skin.netscape.6, skin.mozilla.11), etc.
i am running win2k. i recently installed netscape 7.0 to see what its like and how it compares to mozilla. i already had mozilla 1.1 installed. i had this bug too, but there are other problems with having mozilla and netscape installed on the same machine, even with seperate profiles. i'm sure there are more than a few "browser fanatics" (comment #13) running both browsers. should there be a seperate bug for tracking all netscape-mozilla conflicts?
Hewitt's comment #13 says that only a tiny fraction of users run netscape and mozilla executables against the same profile, but it seems too many such users write for the press, or work in upper mgmt of important companies :-). Can we have a layer of defense in the chrome registry that isn't a hardwired hack? Maybe we need to support some kind of rdf attribute (waving hands here) that ties different chrome components together so that the chrome registry code can be generic, and not hardwire app-component details into its logic. /be
Maybe something could be done along the lines of what we're doing for MRE profile sharing. Part of that is having the profile directory partitioned into shared and non-shared portions on a named client level. If mozilla and Netscape could share the rest of a profile but have separate %Profile%/chrome/chrome.rdf, would this be easier?
renominating
Keywords: nsbeta1- → nsbeta1
Alias: clodern
*** Bug 175089 has been marked as a duplicate of this bug. ***
*** Bug 175296 has been marked as a duplicate of this bug. ***
*** Bug 177114 has been marked as a duplicate of this bug. ***
*** Bug 178456 has been marked as a duplicate of this bug. ***
Summary: using profile across moz and netscape 6 results in "clodern" and "modassic" skins → using profile across moz and netscape 6/7 results in "clodern" and "modassic" skins
nsbeta+/adt2 per the nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
*** Bug 179937 has been marked as a duplicate of this bug. ***
this could be fixed this separately, but fixing whatever netscape bug bug 107694 moved to would resolve this issue...
Depends on: 107694
I am seeing this bug as well, but I am sure that in my case, this is *not* related to a mix of Netscape and Mozilla, because I see it with recent Beonex Communicator (Unix) releases as well, and they use a custom profiles directory, shared neither with Netscape nor with Mozilla. It seems like this appears after I use a new release (both old and new with Modern as default, set via a Select line in install-chrome.txt) on an old profile (which used Modern as well and worked fine before) or when I reuse the profile after a longer time (> 1 week) or something like that -- I have not yet determined the exact steps to reproduce. In any case, I get Modassic as result. (Funny names ;-) .) This might be because I use the wrong (deprecated?) method to set the default theme, in which case I'd be happy to hear the right one.
.
Assignee: hewitt → shliang
I can reproduce it (under Linux) with the following steps: 1. Wipe profiles 2. Build Mozilla as normal 3. Run it. Classic is used (as default skin). 4. run echo "skin,install,select,modern/1.0" >> chrome/installed-chrome.txt in dist/bin 5. Run Mozilla again on the same profile again. Mozilla now uses Modern as default profile, but the profile seems to have artifacts of classic, resulting in modassic. 6. Wipe profiles 7. Run Mozilla again. It uses Modern as default and it looks sane now.
I used 1.0.2 above.
Bryner's fix in bug 180984 (along with upgrading the build machine's version of make for bug 191887) should have fixed the messed up chrome.rdf in Mozilla zip builds that Hewitt mentioned in comment 13. The patch in bug 191954 may help further.
Oh, and if that doesn't fix the problems then removing the three lines: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/rdf/chrome/src/nsChromeRegistry.cpp&rev=1.266&mark=981-983#963 is likely to help further, since those three lines can help cause "global" and "communicator" packages to use one theme and all other packages to use another. (I think the screenshot in attachment 51092 [details] is using modern for global and communicator and classic for navigator, and the screenshot in attachment 51093 [details] is using classic for global and communicator and modern for navigator.)
I don't see why trhese lines are needed at all. - If it's determined from installed-chrome.txt or some magic build order, which theme to use, then the same information should be available at every start, so no need to store it in some extra place (exactly this extra place / redundancy is hunting us here, I think). - If you want to follow the user's choice, then you can't do that anyways (this way), because on many systems (Unix/Linux, some WinNT systems), users are not allowed to write to the install dir.
We are not supporting sharing profiles between Mozilla and Netscape This bug is a duplicate of bug 137164.
Read up. This is not limited to Netscape/Mozilla clashes, but appears whenever the default theme changes. Bug 137164 seems independant.
QA Contact: pmac → gbush
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
I don't see this bug anymore in recent builds. Can someone else verify this?
I still see it using steps above. used mozilla 2003030308 and trunk 2003030404 new profile launches in classic in mozilla and modern in buffy and icons display strangely in modern (will attach screen shot) changing trunk to classic or mozilla to modern and all is well
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt2]
*** Bug 193645 has been marked as a duplicate of this bug. ***
Should this be a blocker for 1.4? I think there are much people out there who want try mozilla and have NS6/7
*** Bug 208163 has been marked as a duplicate of this bug. ***
I just downloaded mozilla 1.4final to determine if I can migrate from my netscape 7.02 browser to mozilla 1.4. I am running w98se with the default skins for netscape 7. I believe I am seeing the same problem that is reported by this bug. The print button and other buttons as shown in screen shot (id 125044) are still showing in the latest download. Mozilla 1.4 - Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 This is not critical to me, but it would be nice to know if it can be worked around. I will be using both old and new for a while to ensure that I can completely switch to Mozilla 1.4.
*** Bug 212846 has been marked as a duplicate of this bug. ***
*** Bug 141617 has been marked as a duplicate of this bug. ***
*** Bug 84041 has been marked as a duplicate of this bug. ***
Flags: blocking1.5?
sounds like benc's comment 22 suggestion of tickling the default skin twice on first start up might be the least amount of work to get this fixed. can someone figure out how to make this change and see if it works? we should try and knock this out in 1.6a..
Flags: blocking1.5? → blocking1.5-
*** Bug 222867 has been marked as a duplicate of this bug. ***
*** Bug 62102 has been marked as a duplicate of this bug. ***
*** Bug 227494 has been marked as a duplicate of this bug. ***
*** Bug 242191 has been marked as a duplicate of this bug. ***
*** Bug 255213 has been marked as a duplicate of this bug. ***
*** Bug 335207 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
no isse andy lo0nger after Netscape is dead
Status: NEW → RESOLVED
Closed: 24 years ago → 17 years ago
Resolution: --- → WONTFIX
vereefight. I liked the bug title: "clodern" and "modassic" :).
Status: RESOLVED → VERIFIED
uhh, i should watch what I type with this new laptop (keyboard)... and yes, "clodern" is one of my favorite bug titles :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: