695977 - Addons shouldn't be compatible by default when their minVersion is greater than the app version

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

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

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: 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

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/integration/fx-team/rev/4d16d843aedd

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

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

[Blair McBride [:Unfocused] (UNAVAILABLE)]

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

[Rob Campbell [:rc] (:robcee)]

https://hg.mozilla.org/mozilla-central/rev/4d16d843aedd

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c7ffb252eed3

Comment 7

[Dão Gottwald [:dao]]

Please use tracking flags for branch landings.

Comment 8

[Virgil Dicu [:virgil] [QA]]

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

[Blair McBride [:Unfocused] (UNAVAILABLE)]

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

[Virgil Dicu [:virgil] [QA]]

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

[Virgil Dicu [:virgil] [QA]]

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