Closed Bug 636235 Opened 15 years ago Closed 15 years ago

disabled extensions get enabled during major update to fx4

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: jbecerra, Unassigned)

References

Details

(Whiteboard: [mu])

If you have some extensions disabled in 3.6.x and go through a major update to Fx4, these extensions get enabled after the jump. This was only seen on Linux. Steps: 1. Install 3.6.14, modify the update channel bit to point to a channel offering a major upate, add a few add-ons like, Adblock Plus, and restart. 2. The add-ons should now be enabled. Go to the add-ons manager and disable it and restart. 3. Check for updates and go through the major update. 4. Look in about:addons Expected: The add-ons that were disabled in 3.6.x should remain disabled. Actual: These add-ons get enabled. At the moment there isn't an MU offer for testing, and I cannot corroborate two separate reports that weren't filed earlier, but it seems a serious enough problem that I'm willing to file as new and nominate for blocking.
blocking2.0: --- → ?
I think this should be a hardblocker for final, it surprises me though, we have tests that are meant to be verifying that the upgrade scenario works. You say it was only seen on Linux, does this mean you've tested on OSX and Windows and not seen it? What were the extensions involved?
blocking2.0: ? → final+
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager
Whiteboard: [mu] → [mu][hardblocker]
Version: 3.6 Branch → Trunk
In theory there should be no difference between doing the whole update process and just running Firefox 4 on an existing 3.6 profile so testing that way should reveal the same issue. In theory.
Assignee: nobody → dtownsend
This scenario was tested across platforms, and Linux was the only platform where this was a problem. I've just double checked the spreadsheet where we tracked these results, and it looks like it also happens by doing a pave over installation: https://spreadsheets.google.com/ccc?key=tQv4xqYkrICJLtvKLZ41zuA#gid=3 So the theory looks proven. The testers didn't say which add-ons were involved, but I can get the profiles later tonight.
I can't reproduce this on my linux machine. I installed 3.6, started a clean profile and installed ShowIP, feedly and Read It Later (all compatible with both 3.6 and 4.0). I disabled feedly and Read It Later and restarted. Then I exited and installed Firefox 4 and started it and as expected feedly and Read It Later were disabled. Can we get more people to try this to confirm one way or another?
Ok two ways that I can reproduce this: If the profile has previously been used with Firefox 4 then any changes made in Firefox 3.6 don't get carried over to 4.0. If you start 3.6, click the disable button for an extension then without restarting exit and start Firefox 4 then Firefox 4 doesn't make the add-on disabled. If these are the only things we're seeing then I don't think this is a hardblocker after all.
Can't reproduce this on my Linux VM. I made a clean profile in 3.6, installed Read it Later, feedly, and Flagfox, disabled them, and upgraded to 4.0. They remain disabled.
(In reply to comment #6) > Can't reproduce this on my Linux VM. I made a clean profile in 3.6, installed > Read it Later, feedly, and Flagfox, disabled them, and upgraded to 4.0. They > remain disabled. Same here.
mmmulani and shorlander also report not being able to reproduce. We should definitely test this when we actually have major updates to try out but until we get confirmed STR I don't think we should block on this anymore.
blocking2.0: final+ → -
Whiteboard: [mu][hardblocker] → [mu]
(In reply to comment #5) > If the profile has previously been used with Firefox 4 then any changes made in > Firefox 3.6 don't get carried over to 4.0. That part is intended behavior, and is similar to how we have handled the transition to signons.sqlite. I will try now if I'm able to somehow reproduce that but as others said earlier, I have never seen that behavior.
No way for me to reproduce anything like what has been reported in comment 0 by starting Firefox 4 right after Firefox 3.6. Looks like we have to wait for the next MU snippets for any further investigation. Adding dependency.
Depends on: 636533
I'm not able to reproduce this problem with Adblock Plus, 1-Click Youtube Video Downloader, Flash and Video Download and Flashgot installed and disabled. I did this the hacky way by requesting a complete update for 3.6.13 and replacing the update.mar with the one for the Fx4b12 complete-update.mar. I'll chat with Andrei later tonight to check the profile details where this was seen.
(In reply to comment #11) > I'll chat with Andrei later tonight to check the profile details where this was > seen. Please also ask for the case if that profile has been ran with Firefox 4 before. I believe that's the case here.
The bug was reproduced during the Major Updates and Paver Over install on Linux (related to extensions) and Windows 7 (related to plugins). A comprehensive study on the disabled/enabled plugins after an update or a pave over install can be found here: http://bit.ly/hMUw2a (IF RELEVANT) The Windows profile used can be found here: http://bit.ly/dTxbUh
I would be happy to test again this issue, but the problem is that I can no longer update from 3.6.14 to 4.b11 by changing the channels-prefs.js. If someone knows a way to do this, leave a comment and I'll get back to you. This is the link http://bit.ly/erCQhP where you can find all the profiles with which the major update was tested.
You will have to wait until the dependent bug has been fixed.
Assignee: dtownsend → nobody
Is anyone seeing this or can we close it?
I have never seen that for profiles which haven't been used with Firefox 4 before. So I would say lets close it. Any objections? Juan? George?
I have not seen this either.
Closing this out then
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.