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.
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.
Attachment #572658 - Flags: review?(dtownsend)
Attachment #572658 - Flags: review?(dtownsend) → review+
Comment on attachment 572658 [details] [diff] [review] Patch v1 Tested, no string changes, an important part of the big addons-compatible-by-default push.
Attachment #572658 - Flags: approval-mozilla-aurora?
Target Milestone: --- → mozilla11
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).
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Attachment #572658 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Target Milestone: mozilla11 → mozilla10
Please use tracking flags for branch landings.
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.
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.
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.
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
Status: RESOLVED → VERIFIED
Depends on: 706424
You need to log in before you can comment on or make changes to this bug.