In Windows XP/7, if you start out with 3.6.14 and add some toolbars and customize them by adding separators, and buttons, those toolbars disappear after doing a major update. Steps: 1. Install a version of 3.6.x set-up for MU, like 3.6.14b(build2) 2. Add some toolbars and customize them. 3. Set it up for major update by changing the channel preferences 4. Restart and go through the major update Expected: All data including added toolbars and their added separators, buttons, etc... remain intact. Actual: Toolbars disappear. Nominating for evaluation.
As described, this is us losing a bunch of user customizations, which kind of sucks. Gavin - can you take a look and lmk if you think we're over-weighting this (re-nom) and/or figure out how we fix it?
I have not been able to look into this yet, but I will first thing tomorrow. Does it really require that you go through the updater, as opposed to manually "upgrading" by running with the same profile in 3.6 and then 4?
It doesn't happen in the pave-over case.
Juan, could you attach localstore.rdf from before and after upgrade?
When I did the MU, I did some screenshots. You can find them attached. No custom toolbar was saved after upgrading to 4.0
Does step 1 involve creating a new profile? Or are you using some existing profile that's been used with Firefox 4? I don't know how to complete Step 3. Changing the channel to "releasetest" or "betatest" offers me an update to 3.6.14 (presumably build 3?). I really see no reason that this could occur in the update-path and not in the normal "upgrade" case of just manually running two builds with the same profile, so I would appreciate confirmation that that is the case.
We need another MU offer to test this because it is no longer available through betatest after the last 3.6.14re-spin. Bug 636533 is for the request.
Can we get some QA assistance with reproducing this?
Having only added a toolbar and several buttons, and fooling the updater to apply a complete Fx4b12 udpate, I cannot reproduce this problem on WinXP. Judging by the screenshots, a lot of add-ons were installed for testing, and this problem could be due to some soft of add-on interaction. I'll chat with the person who tested this later tonight, and ask him details about his profile.
Thanks Juan. This is very helpful. I vote for unblocking on this until we have clear STR. Juan's tests cover the basic use case so I don't think this problem is wide spread, even if it is a bug in our code and not in an extension. Lets not hold the release over it. I am setting this to blocking? to get it re-evaluated.
Please renominate if you can reproduce the issue again
I did some verifications and found that it might be because of the following Extension: Personas 1.6.1 Here is how I got to this conclusion: 1. The major updates were done on 3 different profiles and on 3 different machines (XP, OS 10.5, OS 10.6). 2. Using the STRs in the description the bug was reproduced on XP and OS 10.5 3. The bug was not reproduced on OS 10.6 4. I checked the 3 profiles used and concluded that THE ONLY THING IN COMMON for the OS 10.5 and XP machines and NOT PRESENT on the 10.6 one was the extension Personas 1.6.1. I hope my research is helpful.
I was not able to reproduce the problem on XP and Personas Plus (1.6.1) installed, the added toolbars was still there after the hacky MU.