Closed Bug 529100 Opened 16 years ago Closed 16 years ago

[ACR Extension] Disable compatibility checks during each start-up

Categories

(addons.mozilla.org Graveyard :: Compatibility Tools, defect)

Product:
addons.mozilla.org Graveyard
Component:
Compatibility Tools
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fligtar, Assigned: kinger)

References

Details

I didn't realize the new compatibility checking code apparently made it into 3.6b2, so we need to do this sooner than bug 527249. Please set these preferences to false if they are not already done so when the ACR is running in Firefox. extensions.checkCompatibility.3.6b extensions.checkCompatibility.3.6 extensions.checkCompatibility.3.7a
r56195 has this change. In summary: - On first run, the following four prefs are set to FALSE: extensions.checkCompatibility extensions.checkCompatibility.3.6b extensions.checkCompatibility.3.6 extensions.checkCompatibility.3.7a - On last run (after an uninstall), the above four prefs are reset to whatever value "extensions.checkCompatibility" had when ACR was first run.
Thanks Dave
Assignee: brian → dave
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Component: Administration → Compatibility Tools
QA Contact: administration → compatibility
Hmm... we missed the main use case I was concerned about here and I didn't realize it until I heard some reports. This needs to happen when people upgrade as well, not just on first-run. Everyone that already has the extension and is upgrading to beta 3 today will have their extensions disabled.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #3) > This needs to happen when people upgrade as well, not just on first-run. > Everyone that already has the extension and is upgrading to beta 3 today will > have their extensions disabled. Yes, just ran into this. We'll look into a quick fix.
Is there some sort of update event we can hook into? I don't think so. And we don't have any special code in the extension (yet) to detect updates. And we can't just blindly do a catch-all setting of the pref as it might override those that have already set it back manually. Not sure of the best approach here...
I don't know of any specific upgrade event, but it would be trivial to detect a change in the FF version number after an upgrade and restart. If an upgrade is detected in this way, we then set these prefs to false: extensions.checkCompatibility extensions.checkCompatibility.3.6b extensions.checkCompatibility.3.6 extensions.checkCompatibility.3.7a I'm not sure of the correct behaviour if the user sets any of these back manually at any stage.
I think it is safe to set the pref to false on upgrade once we reach a new version (of the pref). So we've missed out 3.6b with the b2 and b3 releases, but we can set the 3.6 pref when we hit RC.
(In reply to comment #5) > Is there some sort of update event we can hook into? I don't think so. And we > don't have any special code in the extension (yet) to detect updates. And we > can't just blindly do a catch-all setting of the pref as it might override > those that have already set it back manually. > > Not sure of the best approach here... There is nothing specific, but if in profile-after-change there is a mismatch between the pref extensions.lastAppVersion and the property nsIXULAppInfo.version then the app version has changed and the extension manager will be about to enable/disable extensions as appropriate.
Now setting all compatibility prefs to false on browser upgrade. r56446 Would it be wise to disable the compatibility checks on *all* startups? Is there ever a reason why a user would want to enable compatibility checks AND have the ACR extension installed?
(In reply to comment #9) > Would it be wise to disable the compatibility checks on *all* startups? Is > there ever a reason why a user would want to enable compatibility checks AND > have the ACR extension installed? Well, there's always the proverbial "one", and they are usually the most vocal is things conspire against them. Justin's call.
On a related note, I am running ACR 0.3 on Firefox 3.6b3 on Win Vista. I have manually set extensions.checkCompatibility.3.6 and extensions.checkCompatibility.3.6b to false, yet on restart compatibility is still in place and my incompatible extensions are lock disabled. See also: http://armenzg.blogspot.com/2009/11/check-for-add-ons-compatibility-changes.html
(In reply to comment #9) > Now setting all compatibility prefs to false on browser upgrade. I think we still have an issue for people that have already upgraded their browser. I think we should make sure the prefs are disabled on all startups. I am going to be working on better documentation/explanation of the add-on's use and will make sure this is mentioned, but I think it's fine to do.
Brian, Dave, are you guys still up? Would really like to send 0.4 out today with the change on every startup.
(In reply to comment #13) > ... Would really like to send 0.4 out today > with the change on every startup. I'll take this now.
Assignee: dave → brian
Status: REOPENED → ASSIGNED
(In reply to comment #12) > I think we should make sure the prefs are disabled on all startups. Done, r56584.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
The prefs are set on every restart, but first time you won't see them take effect until another restart. I'm not sure force restarting on every startup would be a good user experience.
Thanks - it's working now. Will send out 0.4
Except the behavior I have reported as bug 575272, everything seems to work fine now. Marking as verified fixed.
Status: RESOLVED → VERIFIED
Summary: [ACR Extension] Manually disable compat checking for now → [ACR Extension] Disable compatibility checks during each start-up
Oh, why we set "extensions.checkCompatibility.3.6p"? What is it for?
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.