678616 - Downgrade extensions if doing so provides a compatible version (XPIProvider / onUpdateCheckComplete)

Status: VERIFIED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Derrick Rice (:drice)]

Two things happen within onUpdateCheckComplete.

1) An extension's compatibility information for the currently installed extension-version is updated.  This is called a "compatibility update".  See AUC.getCompatibilityUpdate.

2) If a newer (and compatible) version of the extension is available, it is accepted.  This is your typical "extension update". See AUC.getNewestCompatibleUpdate and the following comparison to this.addon.version.

I propose that a third thing should happen:

3) If the current version of an extension is not compatible, the greatest compatible version should be installed, even if it is *not* an extension update.  That is, take extension downgrades if they provide compatibility where there would otherwise be none.

This scenario is most likely encountered if a user downgrades the application version.  Assuming that the later versions of an extension support later versions of an application and drop support for earlier versions of an application, then it's possible that the application downgrade causes the installed extension to not be compatible.  Previous versions of the extension may offer compatibility.

Note that this scenario is more likely if the author handles application versioning by creating distinct versions of the extension per application version.  For example if v4.0 of myExtension is for FF 4.0 and v5.0 of myExtension is for FF 5.0.  Perhaps I did this because I needed to compile the extension, and did not follow the best practices of including binaries for both application versions in myExtension v5.0 (via chrome.manifest directives).

This scenario may also be encountered if an extension author unwisely creates a future version of the extension that supports only older application versions where it previously supported a wider (and higher) range of application versions. Then a user upgrading the application may find that the installed future version is not compatible, but the application will not take the older compatible version of the extension.



Suggested change would be something like:

let currentIsCompat = AUC.matchesVersions(this.addon, Services.appinfo.version, Services.appinfo.platformVersion);

if (update && 
   ( (Services.vc.compare(newest.version, aUpdates[i].version) < 0) ||
     !currentIsCompat ) ){
...
}

Comment 1

[Derrick Rice (:drice)]

(In reply to Derrick Rice from comment #0)
> Suggested change would be something like:
> 
> let currentIsCompat = AUC.matchesVersions(this.addon,
> Services.appinfo.version, Services.appinfo.platformVersion);
> 
> if (update && 
>    ( (Services.vc.compare(newest.version, aUpdates[i].version) < 0) ||
>      !currentIsCompat ) ){
> ...
> }


I copied the vc.compare from the wrong place.  It should be comparing "this.addon.version" and "update.version".

Comment 2

[Dave Garrett]

There is no guarantee that the extension actually supports downgrading. There may have been some migration for an upgrade, changing saved data in some way, but there would be no reverse path for this in the older extension version.

Additionally, one thing implied with the new rapid release cycle is that downgrades of Firefox are also no longer supported. Once Firefox 5 was released support for Firefox 4 was immediately dropped. This implies that downgrading is completely unsupported unless some LTS release model is adopted in the future.

Comment 3

[Ioana (away)]

Considering comment #2 this is an invalid bug. 
Derrick, please mark it correspondingly.

Comment 4

[Derrick Rice (:drice)]

I am assuming that migrating your profile from one architecture to another is also not supported.  If not, then consider this use case: a user moves his profile from (e.g.) Linux to Windows and his favorite extension supports Linux with extension versions 1.0 - 4.0 but Windows with extension versions 1.0-3.0.  This user would likely find himself with an unusable extension version 4.0 on Windows due to accepting the update on Linux.

(But like I said, I assume that is not supported.  It's a rather strange user behavior, and the goal of the user can better be solved with a syncing mechanism, which probably already exists)

(In reply to Dave Garrett from comment #2)
> There is no guarantee that the extension actually supports downgrading.
> There may have been some migration for an upgrade, changing saved data in
> some way, but there would be no reverse path for this in the older extension
> version.

This is a limitation, yes.  Though with enough motivation, this could be resolved with more information about extension update paths via install.rdf information.  For example, 'can update from' which is by default versions 0.* to $this_version and could be changed to include versions beyond $this_version (therefore allowing downgrades)

> 
> Additionally, one thing implied with the new rapid release cycle is that
> downgrades of Firefox are also no longer supported. Once Firefox 5 was
> released support for Firefox 4 was immediately dropped. This implies that
> downgrading is completely unsupported unless some LTS release model is
> adopted in the future.

So long as this is true and my assumption above is correct, then I agree that my request is invalid.  Thank you for the response.

Comment 5

[Ioana (away)]

Closing bug per the above comments...

Comment 6

[Dave Garrett]

(In reply to Derrick Rice from comment #4)
> I am assuming that migrating your profile from one architecture to another
> is also not supported.

Actually, you should be able to migrate a profile from one OS/arch to another with the exception of any OS/arch specific addons. Most addons are OS/arch independent, however some include files for multiple platforms, some provide separate installers, and some only support certain OSes (e.g. IE Tab is clearly Windows only). There are a few things different per-platform in profiles (the locking mechanism I think) but all the user data is stored in a platform neutral way, as far as I know. The caches might not be portable, though you generally wouldn't care. That being said, there is no built-in profile migrator so you'd have to copy the files yourself, thus I don't know what level of official support there is for this, but it should work.