User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050301 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050301 After installing 1.8b2 build 2005030109 can no longer switch themes Reproducible: Always Steps to Reproduce: 1. Install 1.8b2 build 2005030109 2. open preferences - go to appearances/themes 3. Select under "theme to use" modern or a different theme 4. Theme preview and info appear 5. Click ok 6. dialog box "Theme changes will take effect when you restart mozilla" 7. Quit Mozilla/restart Actual Results: Mozilla restarts with classic theme Expected Results: Should have used modern theme

Mozilla 2005030210 on Mac OS 10.3.8 Hmm, this is odd. I had the same problem, but managed it to work again after some switching/restarts...

Not fixed. 1.8b2 2005030210 Mac OS X 10.3.8 Switching theme in view menu or in preferences has no effect. However, If I change the theme and the profile, restart, change back to the first profile the theme will change This may be a duplicate of 231769

bsmedberg, any idea what's up here?

Not offhand. Are there any chrome JS errors?

Hmm, no related js errors. Going back to an earlier build makes the theme change: 1) change theme (alert shows) 2) restart --> no theme change 3) quit and open a build (using same profile, of course) that works ok --> theme has changed. 4) Open the broken build and notice that the theme has changed. Works fine in a build from 0220. I doubt that it's a dupe of bug 231769. That bug was resolved a long time ago and the symptoms differ.

Can you possibly narrow down when this regressed?

(In reply to comment #6) > Can you possibly narrow down when this regressed? Haven't found any good way to test this yet -- the 2005030109 build now seem to work for me... for some reason. But I wonder if the fix for bug 161751 has something to do with this?

This is also happening on Windows XP. Regression Window: Mozilla Windows Trunk Nightly 2005022805 - Pass Mozilla Windows Trunk Nightly 2005030105 - Fail Each Windows Trunk Nightly from 1-Mar thru 5-Mar also fails. The Preferences module seems to be storing the desired theme, because it doesn't show 'Theme changes will take effect when you restart Mozilla.' when I try again to switch to the Modern theme after restarting the browser. Please update the Hardware & OS fields, and add Regression to the Keywords field.

I'm seeing exactly the same thing under XP. 2/28 build works fine, 3/1 and all more recent builds fail to switch themes. Also, all extensions stopped working for me also as of the 3/1+ builds. Currently installed extensions are no longer recognized, as if not installed, and the installation routine for new ones work, but on restart Mozilla doesn't recognize that anything's been installed. I don't get any errors, and all dialog boxes are as I'd expect for extensions and theme switching, but nothing actually happens. Since both extensions and themes stopped working as of the 3/1 builds, I'm assuming that root cause is the same for both.

WFM here with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050304 Mozilla Calendar 2005022814-cal I did start with a new profile, because calendar wouldn't startup. Even just DL'd Sailfish's Venerable Modern theme for the suite, and it displayed all the proper prompts, restarted, and all is well.

Regression range from comment 8: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-28+05%3A00%3A00&maxdate=2005-03-01+05%3A00%3A00&cvsroot=%2Fcvsroot Likely culprits: Bug 161751

Theme switching always works if you invoke the profile manager during startup.

OK, so the problem is that the chrome registry initialization can occur before, during or after the initial profile switch. Would anyone object to me loading the chrome registry on (say) XPCOM startup, or does anyone have a better idea?

Comment on attachment 177327 [details] [diff] [review] Proposed patch I'm vaguely worried about this patch because I've changed the chrome registry startup order before, and it caused reentrant getservice calls. But if you're willing to deal with that problem if/when it arises, then sure. Perhaps nsChromeRegistry::Observe should have a comment saying that it intentionally ignore the app-startup notification, and that it only exists to force startup initialization?

This is basically a backout of the previous patch, but the profile notification forces a reload of the profile data source. Maybe I should just factor out the skin switching code and call that twice?

*** Bug 286131 has been marked as a duplicate of this bug. ***

Comment on attachment 177355 [details] [diff] [review] New approach The selection code really sucks anyway... anything to make it less evil is fine by me.

Bug 273423 = Duplicate?

(In reply to comment #19) > Bug 273423 = Duplicate? nope, see bug 273423 comment 66.

I don't know if this is pertinent, but I upgraded my Mozilla (Seamonkey) at work to a 2/28 build, which is the last one that didn't have this reported problem. It still let me switch themes, but all of my extensions were no longer recognized. (As if they'd never been installed.) However, unlike later builds, all I had to do to fix this was reinstall them. Strange.

(In reply to comment #21) > I don't know if this is pertinent, but I upgraded my Mozilla (Seamonkey) at work > to a 2/28 build, which is the last one that didn't have this reported problem. > It still let me switch themes, but all of my extensions were no longer > recognized. (As if they'd never been installed.) However, unlike later builds, > all I had to do to fix this was reinstall them. Strange. Could be related to bug 283454 comment 2 and bug 278534 comment 40.

Comment on attachment 177327 [details] [diff] [review] Proposed patch assuming this patch is obsolete

Fix checked in.

*** Bug 286594 has been marked as a duplicate of this bug. ***