Last Comment Bug 734848 - extensions.checkCompatibility.* prefs don't work as expected in ESR releases
: extensions.checkCompatibility.* prefs don't work as expected in ESR releases
Status: VERIFIED FIXED
[qa!]
:
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: 10 Branch
: All All
: -- major (vote)
: mozilla14
Assigned To: Blair McBride [:Unfocused] (UNAVAILABLE)
:
Mentors:
Depends on: 741972
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-12 05:22 PDT by Marc Meltzer
Modified: 2012-04-24 09:24 PDT (History)
12 users (show)
blair: in‑testsuite-
blair: in‑litmus-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
12+
verified


Attachments
screen shot of add-ons manager (95.93 KB, image/png)
2012-03-13 06:37 PDT, Marc Meltzer
no flags Details
compatibility check dialog 1 (14.20 KB, image/png)
2012-03-13 06:38 PDT, Marc Meltzer
no flags Details
compatibility check dialog 2 (15.30 KB, image/png)
2012-03-13 06:40 PDT, Marc Meltzer
no flags Details
Patch v1 (895 bytes, patch)
2012-03-14 19:46 PDT, Blair McBride [:Unfocused] (UNAVAILABLE)
dtownsend: review+
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review

Description Marc Meltzer 2012-03-12 05:22:43 PDT
I know in version 9.0.1, setting

   lockPref("extensions.checkCompatibility.9.0", false)

would disable checking addons during the first launch of the product after upgrading from a previous version.

The same does not appear to be true in 10.0.2, though.  Based on the documentation, I assumed the setting should be

   lockPref("extensions.checkCompatibility.10.0", false);

but when I launch FF 10 after upgrading from version 9.0.1, I am still prompted to check addons compatibility, nor do I see that compatibility checking is disabled when I go into the Add-ons manager, extensions section.

Is anyone aware of this, or is there an alternative setting?
Comment 1 Jorge Villalobos [:jorgev] 2012-03-12 13:03:01 PDT
I think it only would work if you set Firefox to use strict compatibility checking (the boolean preference is extensions.strictCompatibility).

I see you asked the same question in the Enterprise Group. That's the right place to ask, not Bugzilla. If necessary, ask the question again or reformulate it with the new information you have.
Comment 2 Marc Meltzer 2012-03-13 06:34:34 PDT
I still believe this is either a bug, or at the very least, a missing preference.

I have checked every version back to 3.6.16, and the extensions.checkCompatibility.x.y preference is there and works as documented.  With every upgrade (I tested 5.0, 6.0.2, and 9.0.1), I launch FF and see the checking compatibilty dialog box, but I'm not prompted to actually do anything, because I've set the prefs to disable that.  When I upgrade to version 10, however, the preference doesn't do anything.

I've tried extensions.strictCompatibility as you suggested (using both false and true), but neither option worked.
Comment 3 Marc Meltzer 2012-03-13 06:37:15 PDT
Created attachment 605370 [details]
screen shot of add-ons manager

This screen shot shows that compatibility checking is disabled for extensions.
Comment 4 Marc Meltzer 2012-03-13 06:38:47 PDT
Created attachment 605371 [details]
compatibility check dialog 1

After upgrading FF, first launch runs that compatibility checker.
Comment 5 Marc Meltzer 2012-03-13 06:40:01 PDT
Created attachment 605372 [details]
compatibility check dialog 2

If extensions.checkCompatibility.x.y is not set, the user sees this dialog.
Comment 6 Marc Meltzer 2012-03-13 06:41:22 PDT
By the way, the reason I posted here is I wasn't getting much response from the EWG.
Comment 7 Mike Kaply [:mkaply] 2012-03-14 14:04:25 PDT
Jorge,

With the move to "always compatible" did anything change about the extensions.checkCompatibility preference?
Comment 8 Jorge Villalobos [:jorgev] 2012-03-14 14:24:55 PDT
(In reply to Michael Kaply (mkaply) from comment #7)
> With the move to "always compatible" did anything change about the
> extensions.checkCompatibility preference?

My knowledge on the matter goes as far as what I said on comment #1. Copying Blair for a more definitive answer.
Comment 9 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-14 19:11:43 PDT
I assume you're running a 10.0 ESR release? 

It's *meant* to work.... but it seems there's a bug in the way ESR releases are built. Specifically, they're built with MOZ_COMPATIBILITY_NIGHTLY defined - which means the Add-ons Manager uses the extensions.checkCompatibility.nightly pref instead.
Comment 10 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-14 19:42:22 PDT
To clarify: As a work-around until this is fixed, you can use extensions.checkCompatibility.nightly instead of extensions.checkCompatibility.10.0

However, that will stop working once this bug is fixed.
Comment 11 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-14 19:46:55 PDT
Created attachment 606081 [details] [diff] [review]
Patch v1

Short-term solution. Long-tern, I wonder about just using something like --enable-extension-compatibility=branch (defaulting to nightly).
Comment 12 Lukas Blakk [:lsblakk] use ?needinfo 2012-03-20 10:07:54 PDT
[Triage Comment]
If the reviewed patch makes this issue resolved, please go ahead and nominate for approval-esr10, see https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for details.
Comment 13 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-20 21:34:06 PDT
https://hg.mozilla.org/integration/fx-team/rev/6a8e6cb42afa
Comment 14 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-20 21:41:09 PDT
Comment on attachment 606081 [details] [diff] [review]
Patch v1

Not much risk here - it's just a build configuration change, no code change, everything is already tested.
Comment 15 Sridhar 2012-03-20 22:39:24 PDT
Just wondering if I'm missing anything here or is it really a bug. Here is a brief description of the issue that I'm facing-

I'm trying to upgrade Firefox from v3.6.13 to v11.0 (non-ESR version) with the help of complete/partial .mar files and updater.exe on Windows platform. Immediately after the upgrade is complete, the prefs.js under userprofile folder is updated with the following two entries-
user_pref("extensions.checkCompatibility.11.0", false);
user_pref("extensions.checkUpdateSecurity", false);
Upon first launching the browser, the add-ons compatibility check runs. I was under the impression that this issue has been fixed with 11.0 and would basically supresses the compatiblity check by silently disabling the incompatible addons. Has anyone seen this before or am I missing anything here?
Comment 16 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-21 05:53:07 PDT
(In reply to Sridhar from comment #15)
> Upon first launching the browser, the add-ons compatibility check runs. I
> was under the impression that this issue has been fixed with 11.0 and would
> basically supresses the compatiblity check by silently disabling the
> incompatible addons. Has anyone seen this before or am I missing anything
> here?

(This isn't related to this bug, but...)

The extensions.checkCompatibility pref means that addons won't be disabled if they're not marked as compatible (but, as of Firefox 10, most addons are compatible by default anyway). That dialog is an addon update check - it's not affected by either of those prefs. If you want to disable it, set extensions.showMismatchUI to false.

If you have further questions, the dev-apps-firefox mailing list is more appropriate: 
https://lists.mozilla.org/listinfo/dev-apps-firefox
https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.apps.firefox
Comment 17 Lukas Blakk [:lsblakk] use ?needinfo 2012-03-21 13:56:58 PDT
Comment on attachment 606081 [details] [diff] [review]
Patch v1

[Triage Comment]
Thanks for nominating, please go ahead and land.
Comment 18 Marco Bonardo [::mak] 2012-03-21 15:55:08 PDT
https://hg.mozilla.org/mozilla-central/rev/6a8e6cb42afa
Comment 19 Sridhar 2012-03-22 02:16:46 PDT
Thanks Blair, that works!!
Comment 20 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-03-27 04:24:07 PDT
https://hg.mozilla.org/releases/mozilla-esr10/rev/2a79682152cc
Comment 21 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-04-03 21:18:34 PDT
(In reply to Blair McBride (:Unfocused) from comment #11)
> Short-term solution. Long-tern, I wonder about just using something like
> --enable-extension-compatibility=branch (defaulting to nightly).

Filed bug 742132.
Comment 22 Virgil Dicu [:virgil] [QA] 2012-04-17 05:36:31 PDT
Mozilla/5.0 (X11; Linux i686; rv:10.0.4esrpre) Gecko/20120416 Firefox/10.0.4esrpre

I'm still seeing the Check Compatibility dialog and no notification in Add-ons Manager for compatibility checking disabled. 

STR used:

1. Installed Firefox 9.
2. Installed Grafx bot (compatible up to F9-bianry)
3. Set the following prefs in about:config
             extensions.checkCompatibility;false
             extensions.checkCompatibility.10.0;false
4. Manually upgrade to Firefox 10.0.4 Nightly ESR. 
5. Start Firefox using the same profile.

Did I misunderstand in any way?
Comment 23 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-04-17 21:54:03 PDT
(In reply to Virgil Dicu [:virgil] [QA] from comment #22)
> I'm still seeing the Check Compatibility dialog

That dialog is unrelated.

> and no notification in
> Add-ons Manager for compatibility checking disabled. 

This bug only affects release builds, so 10.0.4 Nightly ESR (10.0.4esrpre) is unaffected by this bug/fix.

Mote specifically, it affects builds compiled with --enable-update-channel=esr.

>              extensions.checkCompatibility;false

This pref isn't used anymore, and doesn't do anything. The Add-ons Manager only uses the pref with the matching version in the pref name.
Comment 24 Virgil Dicu [:virgil] [QA] 2012-04-18 01:47:21 PDT
Thanks. Will wait for the official candidate to verify this with "extensions.checkCompatibility.10.0;false".
Comment 25 Virgil Dicu [:virgil] [QA] 2012-04-24 09:24:17 PDT
Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20100101 Firefox/10.0.4

Verified with Windows 7, Ubuntu 11.10 and Mac OS 10.6.
The add-on compatibility checking is disabled notification is now displayed in Add-ons manager after the update.

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