Last Comment Bug 695977 - Addons shouldn't be compatible by default when their minVersion is greater than the app version
: Addons shouldn't be compatible by default when their minVersion is greater th...
: verified-aurora
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: unspecified
: All All
-- normal with 1 vote (vote)
: mozilla11
Assigned To: Blair McBride [:Unfocused] (UNAVAILABLE)
: Andy McKay [:andym]
Depends on: 706424
Blocks: 692664
  Show dependency treegraph
Reported: 2011-10-19 21:46 PDT by Blair McBride [:Unfocused] (UNAVAILABLE)
Modified: 2011-11-30 06:01 PST (History)
5 users (show)
blair: in‑testsuite+
blair: in‑litmus-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch v1 (10.07 KB, patch)
2011-11-07 15:48 PST, Blair McBride [:Unfocused] (UNAVAILABLE)
dtownsend: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-10-19 21:46:11 PDT
Part of making addons compatible by default. Most addons are forward compatible with application versions, but typically not backwards compatible. So when an addon's compatibility for an application specifies a minVersion greater than the application's version, it should be still marked as incompatible.
Comment 1 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-11-07 15:48:48 PST
Created attachment 572658 [details] [diff] [review]
Patch v1

Note that the addon update side of this will be contained in the patch for bug 527141, as it just easier to split it that way.
Comment 2 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-11-13 17:31:34 PST
Comment 3 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-11-13 17:34:29 PST
Comment on attachment 572658 [details] [diff] [review]
Patch v1

Tested, no string changes, an important part of the big addons-compatible-by-default push.
Comment 4 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-11-13 17:47:07 PST
I should probably note that this feature is not currently enabled on Aurora (or Central, for that matter). Assuming we do decide to enable it for Fx10 (see bug 698653), it would be good to have this patch in now rather than later, so it can go through QA's scrutiny (and not suffer bitrot).
Comment 5 User image Rob Campbell [:rc] (:robcee) 2011-11-15 14:11:27 PST
Comment 6 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-11-16 19:38:41 PST
Comment 7 User image Dão Gottwald [:dao] 2011-11-17 00:13:41 PST
Please use tracking flags for branch landings.
Comment 8 User image Virgil Dicu [:virgil] [QA] 2011-11-23 02:26:05 PST
Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111120 Firefox/11.0a1

Attempted to verify using the following steps:

1. Start Firefox 9 Beta2/Aurora 10 with clean profile and flip the extensions.strict to pref to false if necessary (for Firefox9)
2. Manually copy an add-on in the profile folder. 
3. Change its MinVersion in install.rdf to a version higher than 11.
4. Restart Firefox
5. Upgrade to the next available Firefox (Aurora 10 /Nightly 11).

This worked fine on Windows XP, the add-on was displayed incompatible with both Firefox versions, before and after the upgrade.

However, on Ubuntu, the add-on is displayed as compatible before and after the upgrade.
While on Mac OS, the add-on is displayed as compatible only after the upgrade.

Is this expected and is the test case valid on Ubuntu and Mac OS? There aren't any extensions on mac OS and Ubuntu which I know of that are installed via third party applications in the profile folder, so this is unexpected from that point of view.
Comment 9 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-11-23 16:40:57 PST
Er, could you double check that? Firefox 9 doesn't have any of the strict compatibility stuff, so an addon with a minVersion greater than 9 will always be marked as incompatible (though may still be enabled if you've set extensions.checkCompatibility.9.0=false). If it's not being marked as incompatible there, then something was broken before the compatible-by-default bugs landed.

Also, I just tested an addon with a minVersion of 12 on my Ubuntu system. Installing it via the UI failed because it was incompatible, as expected. Placing the file in the /extensions/ directory installed it but it was marked as incompatible, as expected. I didn't do the app upgrade though.
Comment 10 User image Virgil Dicu [:virgil] [QA] 2011-11-24 08:56:22 PST
I think I found out what caused this. Besides other add-ons I used Greasemonkey to check this and changed the MinVersion in install.rdf from 3.6 to 15.6 and Max version to 17.* The add-on is displayed as compatible in any version when changing this.

Indeed it works correctly when setting 12.0 for example as MinVersion. Remains to be checked on Mac, but probably the result there is related to the format used too.
Comment 11 User image Virgil Dicu [:virgil] [QA] 2011-11-30 06:00:15 PST
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111129 Firefox/11.0a1

Actually, it seems that the real reason for the strange results was AMO compatibility updates, as Blair suggested in another thread.

This works correctly when using the STRs in comment 8 without an Internet connection. Checked Mac OS 10.6, Ubuntu 11.10, Windows XP, 7.

Filed bug for the behavior spotted with updates from AMO during downgrades: bug 706424

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