Last Comment Bug 709225 - ACR 1.0.1 high-handedly (and silently) removes my extensions.checkCompatibility.* prefs at every startup
: ACR 1.0.1 high-handedly (and silently) removes my extensions.checkCompatibili...
Status: RESOLVED FIXED
: regression, ux-control
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Compatibility Tools (show other bugs)
: ACR-1.*
: All All
: -- major
: ACR-1.0.2
Assigned To: David McNamara [:mackers]
:
Mentors:
: 709197 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-09 11:22 PST by Tony Mechelynck [:tonymec]
Modified: 2016-02-04 14:48 PST (History)
9 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Tony Mechelynck [:tonymec] 2011-12-09 11:22:08 PST
Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111209 Firefox/11.0a1 SeaMonkey/2.8a1 ID:20111209003002

ACR 1.0.1

I have

  user_pref("extensions.checkCompatibility.nightly", false);

as one of the lines in my user.js; yet with ACR 1.0.1 installed, I notice that:
- Filtering about:config on ns.ch only shows a couple of prefs, with names ending in .previous (presumably used by the ACR), not the one set by the above line
- in the Extensions (list) tab of the addons manager, several extensions which work for me and upon which I rely are shown with "This extension will be disabled at next restart".

Even if they aren't, too much is too much. The ACR has outlived its usefulness for me, I'm disabling it and going back to extensions.checkCompatibility.nightly (and if necessary, extensions.checkCompatibility.2.8a et al.)


This didn't happen with ACR 1.0
Comment 1 Tony Mechelynck [:tonymec] 2011-12-09 11:30:15 PST
Adding to the CC a few people who I think might be interested.
Comment 2 Tony Mechelynck [:tonymec] 2011-12-09 12:23:11 PST
I suspect this might be due to the fix for bug 708931. When extensions.strictCompatibility is false (the default in this version of SeaMonkey), ACR should perhaps not disable compatibility checks, but neither should it clear compatibility prefs *intentionally set by the user*.
Comment 3 Jorge Villalobos [:jorgev] 2011-12-15 09:16:32 PST
*** Bug 709197 has been marked as a duplicate of this bug. ***
Comment 4 David McNamara [:mackers] 2011-12-17 04:58:44 PST
(In reply to Tony Mechelynck [:tonymec] from comment #2)
> I suspect this might be due to the fix for bug 708931. When
> extensions.strictCompatibility is false (the default in this version of
> SeaMonkey), ACR should perhaps not disable compatibility checks, but neither
> should it clear compatibility prefs *intentionally set by the user*.

Agreed. ACR behaviour for compat-by-default browsers is now:

- checkCompatibility user prefs are not touched on startup
- uninstalling ACR won't reset checkCompatibility prefs

r99000

Note You need to log in before you can comment on or make changes to this bug.