As stated in the summary: the first time you launch Firefox after an upgrade, if you're using a third-party theme, you see browser chrome having a mix of themed and unthemed elements, as if the theme is only partially applied. See the screenshot. http://i54.photobucket.com/albums/g112/mcdavis941/bugNNNNNNunthemedOnAppUpgrade.png STR: 1 - Make sure you have both Fx4.0b8pre and Fx4.0b9pre installed 2 - Start Fx4.0b8pre with a fresh profile 3 - Go to about:config, set extensions.checkCompatibility.4.0b=false (may or may not be needed based on whatever addons you're testing with) 4 - Install a theme (not a persona), select that theme, restart with it 4.1 - https://addons.mozilla.org/en-US/firefox/addon/14313/versions/ (along with several others) will show this bug 5 - Notice everything looking relatively normal with the theme 6 - Exit Firefox 7 - Start Fx4.0b9pre (a version jump from b8pre to b9pre, representing an app upgrade) with the same profile used in step 2 8 - Notice the checks for updates to installed addons (because it's a browser upgrade) after which the app finishes launching normally 9 - Look at the main browser UI and notice several parts of the UI don't use the theme's style (scrollbars, buttons, etc.) while others do honor the style specified by the theme ... it's as if native desktop -moz-appearance values are being used even when the theme specifies -moz-appearance: none Expected Result: - Theme applies to UI as usual. Actual Result: - Theme is only partially applied, resulting in a mix of themed and unthemed elements in browser chrome. - This error only shows up the first time Firefox is launched after an upgrade. After that, on every subsequent launch, it works normally and as expected. - Vista 64 - Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0b8pre) Gecko/20101204 Firefox/4.0b8pre - Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0b9pre) Gecko/20101223 Firefox/4.0b9pre I think I saw this on the previous app upgrade (from b7pre to b8pre) too, so I wouldn't draw any conclusions about regression ranges from the Minefield versions shown above.
At a guess showing the compatibility UI (I'm assuming that shows in the default theme even when a custom theme is enabled?) is causing us to cache part of the default theme and then we don't correct that afterwards.
blocking2.0: --- → ?
Maybe startup, maybe add-ons manager, not sure just yet
blocking2.0: ? → final+
Component: General → Add-ons Manager
QA Contact: general → add-ons.manager
Reporter, do you also see this behavior when you delete the XUL cache before the first start with b9pre?
(In reply to comment #3) > Reporter, do you also see this behavior when you delete the XUL cache before > the first start with b9pre? No, it's the same either way (assuming you're talking about deleting XUL.mfl from the profile directory). I used the same STR as above, but added step 6.5 - delete XUL.xml Sometimes there is no XUL.mfl to delete (watching the profile directory in Windows Explorer, and being sure to refresh so the view is current), but again it's the same outcome (mix of themed and un-themed) either way.
The XUL.mfl should not be located in the profile but here: C:\Documents and Settings\<username>\Local Settings\Application Data\Mozilla\Firefox\Profiles
(In reply to comment #5) > C:\Documents and Settings\<username>\Local Settings\Application > Data\Mozilla\Firefox\Profiles Could that be a partial path? It doesn't match what I thought I knew or what I'm seeing. Anyway, my install is non-standard. I keep all my several profiles together in D:\profiles, and always launch Firefox with the Profile Manager to pick the one I need. In this case, the location of the profile used in the test is D:\profiles\freshupgtest\, and that is where I saw XUL.mfl when present. (In case you're wondering if there's something wrong with my custom installation .. I did ask other people to check if they saw the same behavior as me, and it was confirmed.)
I can confirm this bug, it happens every time when I switch to FF3.6 for testing, It happens always on the way back to FF4Beta (any beta for a long time). I'm using the same profile for both (as will the average user). Many users are reporting this bug (hundreds in the compatibility feedback). I hope it can be fixed because it's the most serious visual bug I've seen that seem to effect all 3rd party themes. (Tested on LavaFox & BlackFox Themes)
Ok, I can confirm this problem now. It should be a regression. The last time I have tested this path (not exactly sure when it was), something like that I haven't seen. I will check for the regression range.
Keywords: regression, regressionwindow-wanted
OS: Windows Vista → All
Hardware: x86 → All
Thanks for looking into it [:whimboo]
Regression window is between 10081703 and 10081803: PASS: http://hg.mozilla.org/mozilla-central/rev/116f2046b9ef FAIL: http://hg.mozilla.org/mozilla-central/rev/f4c97baa0e51 Check-ins: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=116f2046b9ef&tochange=f4c97baa0e51 There were quite a lot of check-ins. I will start a bisect to narrow it down a bit more.
(In reply to comment #10) > Regression window is between 10081703 and 10081803: > > PASS: http://hg.mozilla.org/mozilla-central/rev/116f2046b9ef > FAIL: http://hg.mozilla.org/mozilla-central/rev/f4c97baa0e51 > > Check-ins: > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=116f2046b9ef&tochange=f4c97baa0e51 > > There were quite a lot of check-ins. I will start a bisect to narrow it down a > bit more. Bug 557956 is in the range, before then we didn't show the compatibility UI at all. I'm pretty sure I already know what is going on here anyway.
Right, my last range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4fd842de2365&tochange=ab6e93fb7fec If you know what's going on it's great! So I will stop bisecting now. Does it mean it has been made visible with the fix on bug 557956?
(In reply to comment #12) > Right, my last range is: > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4fd842de2365&tochange=ab6e93fb7fec > > If you know what's going on it's great! So I will stop bisecting now. Does it > mean it has been made visible with the fix on bug 557956? Bug 557956 will have exposed the problem but it is really cause by bug 576553
Assuming we can detect this case, I think we can flush... something. What parts of the UI are mixed? Is it just images, or also CSS and other elements?
(In reply to comment #15) > Created attachment 502014 [details] > screenshot > > Here a screenshot with the Walnut theme. That's not so messy ... My themes (LavaFox & BlackFox)look much worst on first run when I switch from FF3.6 to Beta. The app-menu button isn't skinned, the tabs aren't skinned, there are all the toolbar icons spread all over the toolbar (without -moz-region to display the right image) etc. I don't know how to attach a screenshot (my first time here), if anyone likes to see a very messy example, please try one of my themes.
You can upload a screenshot by clicking on "Add an attachment" right below the attachment box at the top of the page.
Here's a screenshot of LavaFox displaying the bug. To reproduce: 1. First I already had the LavaFox theme installed on FF4.0Beta9 2. I closed the Beta & opened FF3.6 (which reverted automatically to the default theme & asked to re-install webmail, NoScript & AdBlock Plus). 3. I reinstalled LavaFox that disappeared from the add-ons window of FF3.6. 4. I closed FF3.6 & opened the Beta (that's what you can see in the screenshot) *Notice that all the bookmarks icons reverted to the default image! *Scrollbars aren't skinned *Tabs aren't skinned *App-Menu button isn't skinned *Restarting the Beta solves the unskinned areas (but I stay with the default bookmarks icons)
(In reply to comment #14) > Assuming we can detect this case, I think we can flush... something. What parts > of the UI are mixed? Is it just images, or also CSS and other elements? Basically anything loaded through skin urls are getting cached including chrome://global/skin/global.css. Clearing the XUL caches after showing the compatibility UI solves the problem.
Whiteboard: [input] → [input][waiting on try]
This moves the cache clearing to after the compatibility wizard may have shown and also makes sure we always clear the caches in that case.
Attachment #502524 - Flags: review?(robert.bugzilla)
Whiteboard: [input][waiting on try] → [input][has patch][needs review rs]
Attachment #502524 - Flags: review?(robert.bugzilla) → review+
Whiteboard: [input][has patch][needs review rs] → [input][has patch]
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [input][has patch] → [input]
Target Milestone: --- → mozilla2.0b10
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre
Status: RESOLVED → VERIFIED
This is a lot better now, thank you. Almost all the problem areas from the initial bug report seem fixed. However, it looks like scrollbars are still having the same problem. After updating to 4.0b11pre, scrollbars were still unthemed (drawn in native desktop style) even though I was using an em:type=4 theme. As before, after one more restart of Firefox, they're drawn as expected.
Can you please file a new bug and specify which theme you are using? Thanks.
Sure, will do.
(In reply to comment #24) > Can you please file a new bug and specify which theme you are using? Thanks. Filed bug 629869 for this.
You need to log in before you can comment on or make changes to this bug.