Closed Bug 47081 Opened 24 years ago Closed 24 years ago

Skin switching broken *iff* more than one profile

Categories

(SeaMonkey :: Themes, defect, P3)

Product:
SeaMonkey
Component:
Themes
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: gabriel, Assigned: hyatt)

References

Details

(Whiteboard: nsbeta3+) 

Linux build 2000073009.

Clicking on the categories on the left selects the category, but the frame on
the right does not change. (The navigator pane on the right shows no radio
buttons checked, you can enter text in the homepage box, but clicking OK does
not save it).

I imagine you are aware of all this, and are still developing the classic skin,
but just in case...

Oh, and I am now also stuck in Classic skin (since I can't change themes back).
Might I suggest you at least fix the theme pref, so that it is possible to
switch back to modern. If the title is too general you could change it to
'Mozilla gets stuck in Classic skin.'
Yes, I noticed that myself this morning on 2000073108. Marking New
Status: UNCONFIRMED → NEW
Ever confirmed: true
dang, i've run into this with y'day's and today's branch builds on the Mac. not
sure how to repro this... has anyone got some reproducible steps here? one thing
i noticed is that when switching from modern->classic on a fresh profile, i
don't get this problem. but i've seen this happen with existing profiles, so i'm
unsure what had happened that'd cause this.
Keywords: dogfood, nsbeta3, relnote2
OS: Linux → All
Hardware: PC → All
->themes

(not happening on windows, btw...)
Assignee: ben → hangas
Component: Skinability → Themes
QA Contact: BlakeR1234 → paw
well, here's a crack at some steps, using 2000.08.03.04-m17 [comm, branch] on
Mac. gabriel/shrir/paw/blake, lemme know if you can confirm these steps on other
platforms.

1. start with profile manager.
2. create a new profile and start the browser with it.
3. go to Prefs > Themes.
4. select the classic skin.
5. click the Switch Skins button.
6. click Ok to the dialog that appears. observe how the prefs dialog's skin is
updated as well as the navigator window in the background (as expected).
7. click OK to save/dismiss the Prefs dialog.
8. bring up Prefs dialog again. observe that the classic theme still looks fine,
and that you can select other pref categories (as expected).
9. dismiss Prefs.
10. quit and restart browser with the recently created profile.
11. bring up Prefs.

results/observe:
* the classic theme is no longer applied to the Prefs dialog.
* widgets within the Prefs dialog are unresponsive.

are we stuck relnoting this for beta2?
Component: Themes → Skinability
QA Contact: paw → BlakeR1234
Summary: [SKINS] Prefs totally broken under Linux classic skin → [SKINS] Prefs totally broken under classic skin
sorry, blake, i clobbered your and prolly others' changes by accident. feh.
Component: Skinability → Themes
gabriel, have you tried a more recent build on linux? i'm using today's branch
[2000.08.03.04-m17] and cannot repro (aggravatingly) there.

seems only to be repro on the Mac branch bits.

blake, i take it this is np on win32 branch *or* trunk...?
np
QA Contact: BlakeR1234 → paw
Aaargh. I tested this a couple of days ago on all three platforms and had no
problem, *but* I missed sairuh's critical step above -- this must be on a 
with two or more profiles *and* doing the skin switching for one of them.

On linux and win32, this leads to the curiosity that the prefs dialog has the
modern skin, while the rest of the apps have a classic skin. However, this
prefs dialog is full functional.

However, on mac, with 2000080404 PR2 build, the prefs dialog (in addition to 
the wrong skin) is *not* functional. This is bad. (However, on one occasion,
for unknown reasons, after using the browser/mailnews/aim/etc. for a while,
the prefs panel started working).

i also was able to repro this using mozilla bits on the Mac, using branch bits
2000.08.04.15-m17. ergh.
Changing summary from "Prefs totally broken under classic skin"

I spoke with michaell about this, and this is not a blocker for PR2. (We all
agree this is painful, but not the end of the world).

The release notes must be clear on this point though, so here is my suggested
text (cc: verah).

Themes
  Macintosh
    If you have more than one profile (either by creating a new one, or by
   migrating more than one Netscape 4.x profiles), you should not switch to
   the Classic theme. If you do select the Classic theme for a profile, you
   will no longer be able to use the preferences dialog to change any
   preferences, including changing back to the Modern theme for that profile.
   (The rest of the application will, however, work correctly). If you wish
   to use the Classic theme on Macintosh, you must ensure that you only have
   one profile created.
Summary: [SKINS] Prefs totally broken under classic skin → Prefs broken using classic skin *iff* more than one profile
Typo:
  this line    "either by creating a new one"
  should read  "either by creating more than one"

I am told this needs some hyatt/danm love -- the per-profile bookeeping for
selected skins seems to not be tracking the skin change for the preferences dialog.

(While this is nominated for dogfood, it is not dogfood as the workaround
is "*smack*, don't do that". However, this one is a clear stopper for nsbeta3).
Assignee: hangas → hyatt
Severity: critical → major
Keywords: dogfood
wfm now under linux build 2000080505.

I think I'm only using one profile though. Not sure what a profile is, but I'm
using multiple users, root and a normal user.

*** Bug 48077 has been marked as a duplicate of this bug. ***
*** Bug 48077 has been marked as a duplicate of this bug. ***
This is absolutely not the chrome registry's bug.  I can watch it resolve to the 
correct resource URLs.  In fact, I can even corrupt the second profile and still 
run the first profile just fine, even when the two profiles have IDENTICAL RDF 
files for their current skin.  I even tried copying the user-skins.rdf file from 
the first profile to the second.

In the first profile, everything worked.  In the second, everything is 
corrupted.  Somehow (and I really don't know how) we're loading files from the 
modern directory even when the classic directory is always specified.

I am baffled.

This is much worse than prefs being broken.  It makes skin switching unusable 
with more than one profile.  On Win2k I get completely corrupted, with my 
main window being a mixture of modern and classic files.

Some more info.

I have profile A, uncorrupted.  Profile B is corrupted.  If I delete A, and then 
exit, and then run, profile B comes up just fine.

So this is a profile problem.
Summary: Prefs broken using classic skin *iff* more than one profile → Skin switching broken *iff* more than one profile
Whiteboard: nsbeta3+
*** Bug 47517 has been marked as a duplicate of this bug. ***
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
BTW, this absolutely was the chrome registry's bug after all.  Hahahaha.  I 
suck.

*** Bug 48499 has been marked as a duplicate of this bug. ***
QA Contact: paw → pmac
Updated QA contact
This fixed accross all platforms (Build: 2000082508M18).
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.