698355 - Add compatMode parameter to VersionCheck.php to allow updating to non-compatible addon versions

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: API, defect, P2)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

In bug 527141, I want to send an additional parameter ("compatMode") in the version update check, denoting what type of compatibility mode the extension manager is running in.

The three possible values are:
* strict - old-style compatibility checking, where addons are compatible only if they explicitly say they are. This is the same as the current behaviour.
* normal - Addons are compatible by default. Same as "strict", except ignore the maxVersion - but only if it doesn't have a matching compatibility blacklist entry (see bug 692971).
* ignore - when compatibility checking is disabled (ie, the extensions.checkCompatibility.VERSION pref is set to false). Same as "normal", except it ignores any compatibility blacklist.

If the parameter is missing, it should be interpreted as "strict", so that old application versions get the same response as they do currently.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Almost forgot... addons can opt-in to strict mode. See bug 698358. So if Firefox sends compatMode=normal, but the addon has opted-in to strict compatibility mode in it's install.rdf, then VersionCheck.php should assume compatMode=strict

Comment 2

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #1)
> Almost forgot... addons can opt-in to strict mode. See bug 698358. So if
> Firefox sends compatMode=normal, but the addon has opted-in to strict
> compatibility mode in it's install.rdf, then VersionCheck.php should assume
> compatMode=strict

Can't we just send strict in this case to make things simpler on the server?

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #2)
> Can't we just send strict in this case to make things simpler on the server?

We can, and my patch does this, but it needs to be able to handle the case where the installed version doesn't opt-in, but the newer version does (and is incompatible). Otherwise it'll try to upgrade to an incompatible version - which will happen the first time any addon opts-in (this will primarily affect people running nightly/aurora/beta).

Comment 4

[Dave Townsend [:mossop]]

Actually I think it's not clear to me what this is about. We send compatMode to AMO in the URL? What is AMO going to use this for? Don't we also need compatMode to be included in the returned update.rdf so Firefox knows how to interpret the min/maxVersion info?

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #4)
> Actually I think it's not clear to me what this is about. We send compatMode
> to AMO in the URL? What is AMO going to use this for? 

Yep, because currently AMO will only send information about one update - the one it thinks is the latest that's compatible with the application version specified by the appVersion parameter in the URL.

> Don't we also need
> compatMode to be included in the returned update.rdf so Firefox knows how to
> interpret the min/maxVersion info?

We don't *need* it when it comes from AMO, since AMO only sends one update - we can just assume it sent an update that's compatible.

But it will be needed for the update.rdf for addons that update outside of AMO - but only when they opt-in to strict compatibility checking.

Comment 6

[Wil Clouser [:clouserw]]

I talked with a few devs today and what this bug needs isn't clear to us.  Can we meet today and/or have more explanation of what AMO is doing?  It sounds like filtering out stuff would be client side but I think we're just not understanding the bug.

Comment 7

[Wil Clouser [:clouserw]]

Info here: https://etherpad.mozilla.org/jlkasdfjksadj

Comment 8

[Rob Hudson [:robhudson]]

https://github.com/mozilla/zamboni/commit/22ae51f