691832 - "Update Compatibility" not providing proper update manifest

Status: RESOLVED WONTFIX

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

Description

[support]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110916091512

Steps to reproduce:

We modified the compatible version of our add-ons with the "Update Compatibility" feature of AMO.  This was intended in this case to make our add-on compatible with the recent upgrade to FF 7.0


Actual results:

Our users are reporting compatibility problems with the recent FireFox 7 upgrade *despite* having updated our compatible version number withing AMO.  The add-on is getting disabled and then while they can re-install it gets disabled on them again.

We had this same problem earlier with another of our add-ons, so we dug into this a little and here's what we think is happening (and ***note that we have a code-signed xpi's***):

  The logic that firefox uses to do compatibility is explained here:  https://developer.mozilla.org/en/Extension_Versioning%2C_Update_and_Compatibility#Compatibility_Updates

    During the automatic update checks, applications look for both new versions and updated compatibility information about the currently installed version of an add-on. This means that if your update manifest contains an entry for the currently installed version of the add-on, and the entry's targetApplication entry specifies a larger maxVersion then the application will use this value instead of that specified in the add-on's install.rdf. This can cause add-ons that are disabled for being incompatible to become enabled and add-ons that would normally not install to be installed.

So then to verify update manifest sent by AMO we did following tests:

     a. When we had FF v6.0.2 and PrivacySuite 0.736 (our add-on installed from amo), find updates request sent this request to amo.

https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=[e-mail]&version=0.736&maxAppVersion=6.*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=6.0.2&appOS=Darwin&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=6.0.2&updateType=97

(this returned PS v. 0.739 manifest)

We then switched back to 7.0.1 and during startup it sent following request to AMO:

https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=[e-mail]&version=0.736&maxAppVersion=6.*&status=userEnabled,incompatible&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=7.0.1&appOS=Darwin&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=7.0.1&updateType=35

and the response had the 0.739 update manifest.  Since it couldn't find a matching version (0.736) and install.rdf of 0.736 had maxversion as 6.* it marked that add-on as incompatible.  We also looked at code ./toolkit/mozapps/extensions/AddonUpdateChecker.jsm and it considers update manifest only if the version number matches exactly:

    if (Services.vc.compare(aUpdates[i].version, aVersion) == 0)


Expected results:

It looks like to fix this issue and make the compatible version changer feature of AMO work then AMO has to send a different update manifest (which includes all versions of addon or the requested version of addon).

Comment 1

[Justin Scott [:fligtar]]

So the problem is that you are using an old version of the add-on (0.736) and refusing to upgrade to to the newer version, so it's being disabled, even though you updated the maxVersion of the old version on AMO?

Comment 2

[support]

We've actually seen two different cases where this is an issue:

Scenario 1:
1. User has amo version of add-on, with 'old' xpi but updated via AMO compatibility updater
2. User upgrades to FF7
3. During upgrade, FF checks addons for compatibiliy and disables add-on

Scenario 2:
1. User has FF7 already
2. Installs 'old' xpi from AMO (u/updated version via updater) then does initial restart
3. Restarts FF again and add-on is disabled

Then after either of these two "starts" we see the following chain of events:
4. User comes to us asking why the add-on isn't working
5. User gets instructions to reinstall add-on
6. Everything works ok
7. FF prompts user to upgrade to 7.0.1
8. Add-on is disabled again

Comment 3

[Andrew Williamson [:eviljeff]]

In what circumstances would the user not just update to a new version of the add-on?

It doesn't affect the validity of the bug, but it'd be useful to know what users are being effected by the issue.

Comment 4

[support]

These are cases where there is not a "new" version of the add-on available.  I must not have made that clear.

These are cases where:
1. A code-signed xpi has been submitted to AMO and approved.
2. The compatible version for the add-on is adjusted via the update compatibility function.
3. A new version of FF comes out.
4. These issues arise.

It may well be that in the meantime a new xpi is being developed and/or submitted for review but has not yet been completed or approved.  

I would think the ideal result of this would be for compatibility ranges *within* the xpi to be tightly constrained (instead of everybody just using 8.*), but with the ability to not have to submit new XPIs as FF versions change and just validating and updating the compatible version via AMO - changing the install.rdf in the XPI as other changes are made to the add-on etc.

Comment 5

[Wil Clouser [:clouserw]]

Jorge: can you explain what the steps to fix this bug are?

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

1) Try to reproduce using comment #2 and comment #4, with the 6->7.0.1 and the 7.0->7.0.1 upgrades.
2) If we can reproduce, we need to figure out why the API is giving Firefox incorrect data. If the data is correct, then this would be a bug in the Add-ons Manager.

Comment 7

[Wil Clouser [:clouserw]]

Sounds like QA is up on this.  Thanks.

Comment 8

[Wil Clouser [:clouserw]]

Thanks for filing this.  Due to resource constraints we are closing bugs which we won't realistically be able to fix.  If you have a patch that applies to this bug please reopen.

For more info see http://micropipes.com/blog/2014/09/24/the-great-add-on-bug-triage/