Upgrading incompatible add-ons

[Blair McBride]

tl;dr version: Should ignoring addon compatibility checks also apply to
addon upgrades?


Currently, the extensions.checkCompatibility.* prefs that control add-on
compatibility checking only apply to add-on installs. This means the
Add-ons Manager won't upgrade to an incompatible version of an add-on
even if you've explicitly opt-ed in to ignore compatibility checks.

In The Great Add-ons Manager Re-write, it was kept this way both for
historical reasons (it's always been this way), and for fear of an
incompatible upgrade breaking something.


However...

* An older version of an incompatible add-on is arguably just as likely
(if not more likely) to break, than a newer version that's also
incompatible.
* On Nightly, it's almost guaranteed that if you want to use add-ons,
you want to use one that's not yet marked as compatible. So if you're on
Nightly, you probably have outdated add-ons.
* If you're running an add-on that's not marked as compatible, you'll
also miss out on security updates for that add-on.
* Ignoring compatibility checks is opt-in. You're explicitly saying that
you're aware that things may break.
* (And various other comments in bug 527141)


So, I propose the following changes:

* Ignoring add-on compatibility checks should also apply to add-on updates
* But only when the update's compatibility is for older versions of the
application (if it's only compatible with a newer version of the
application, then the add-on won't be upgraded)
* Make this change apply to all branches (not just Nightly).


Does this sound reasonable to everyone? Any objections?

- Blair
(One of your friendly Add-on Manager hackers)

[Robert Strong]

+1 - it really should behave this way though when doing a rewrite or
coming up on a release it is the right move to not make the change since
it could introduce regressions.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
Cheers,
Robert Strong

[Robert Strong]

One concern though is if there is an api change that an extension uses.
So, when running Firefox 10 in this scenario if extension version 1 is
compatible with Firefox 10 but not with Firefox 11, extension version 2
is compatible with Firefox 11 but not with Firefox 10, and the pref is
set then then they would get extension version 2 when they really want
extension version 1. I haven't thought this through much so this
scenario might be incorrect or there might be a way to mitigate this
from happening.

Robert

[Will Roberts]

On 10/04/2011 10:37 PM, Robert Strong wrote:
> One concern though is if there is an api change that an extension uses.
> So, when running Firefox 10 in this scenario if extension version 1 is
> compatible with Firefox 10 but not with Firefox 11, extension version 2
> is compatible with Firefox 11 but not with Firefox 10, and the pref is
> set then then they would get extension version 2 when they really want
> extension version 1. I haven't thought this through much so this
> scenario might be incorrect or there might be a way to mitigate this
> from happening.
>
> Robert
>

I believe that's covered in Blair's 2nd point, no?

[Robert Strong]

On 10/4/2011 7:58 PM, Will Roberts wrote:
> On 10/04/2011 10:37 PM, Robert Strong wrote:
>> One concern though is if there is an api change that an extension uses.
>> So, when running Firefox 10 in this scenario if extension version 1 is
>> compatible with Firefox 10 but not with Firefox 11, extension version 2
>> is compatible with Firefox 11 but not with Firefox 10, and the pref is
>> set then then they would get extension version 2 when they really want
>> extension version 1. I haven't thought this through much so this
>> scenario might be incorrect or there might be a way to mitigate this
>> from happening.
>>
>> Robert
>>
>
> I believe that's covered in Blair's 2nd point, no?

Thank you and it is.

>
>>> On 10/4/2011 7:27 PM, Blair McBride wrote:
>>>> So, I propose the following changes:
>>>>
>>>> * Ignoring add-on compatibility checks should also apply to add-on
>>>> updates
>>>> * But only when the update's compatibility is for older versions of
>>>> the application (if it's only compatible with a newer version of the
>>>> application, then the add-on won't be upgraded)
>>>> * Make this change apply to all branches (not just Nightly).

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
Cheers,
Robert Strong

[Henri Sivonen]

On Wed, Oct 5, 2011 at 6:02 AM, Robert Strong <rst...@mozilla.com> wrote:
> On 10/4/2011 7:58 PM, Will Roberts wrote:
>>

>> On 10/04/2011 10:37 PM, Robert Strong wrote:
>>>
>>> One concern though is if there is an api change that an extension uses.
>>> So, when running Firefox 10 in this scenario if extension version 1 is
>>> compatible with Firefox 10 but not with Firefox 11, extension version 2
>>> is compatible with Firefox 11 but not with Firefox 10, and the pref is
>>> set then then they would get extension version 2 when they really want
>>> extension version 1. I haven't thought this through much so this
>>> scenario might be incorrect or there might be a way to mitigate this
>>> from happening.
>>>
>>> Robert
>>>
>>
>> I believe that's covered in Blair's 2nd point, no?
>

> Thank you and it is.

The point was:

>>>>> * But only when the update's compatibility is for older versions of
>>>>> the application (if it's only compatible with a newer version of the
>>>>> application, then the add-on won't be upgraded)

If extension version 1 is compatible with Firefox 10 and version 2 of
the extension is compatible with Firefox 11 but not 10, what's the
plan for making Firefox and the extension update together so that the
user sees no incompatibility warnings or other unsmoothness?

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[emanuel....@gmail.com]

>If extension version 1 is compatible with Firefox 10 and version 2 of
>the extension is compatible with Firefox 11 but not 10, what's the
>plan for making Firefox and the extension update together so that the
>user sees no incompatibility warnings or other unsmoothness?

When upgrading to a new version, the installer checks for updated extensions, no? While on Firefox 10, an extension update marked as requiring at least Firefox 11 would not show up (and possibly shouldn't install in the first place even with extensions.checkCompatibility.nightly == false, but that's a different discussion). Then during installation of the upgrade, it would be updated.

But if there's a version of the extension out that's compatible with the version of Firefox that you're upgrading to, this bug doesn't apply in the first place right?

[dennis....@gmail.com]

+1 I'm running Firefox 8 beta, Aurora, and Nightly. I switch between them, using a common profile.

I have a *lot* of addons installed (93 at the moment), and I test Beta, Aurora, and Nightly builds largely to see if any addons *do* break on an upgrade. Addons Compatibility Reporter is my friend.

Addons are both a major strength and a major weakness in Firefox. They are a strength because the ability to extend Firefox via addons is probably the single biggest feature of Mozilla products. Other browsers are following in FF's wake with an extension capability, but they offer nowhere near as much power in doing so. They are a weakness because every time a new version comes out, a bunch of things get marked as incompatible and stop working. The user must either download the XPI, extract and edit the install.rdf, stuff it back in and install locally, or use something like ACR to turn of compatibility checks. This problem gets *much* worse with the new rapid release model, and a new major version every three months.

I certainly want "incompatible" addons checked for updates. At a rough guess, about 2/3 of what I currently run is "incompatible". The update I'm *not* being informed of might be the one that *makes* it compatible. I won't know unless I happen to go to AMO to check.

I want to be able to install an addon that is incompatible, with only a warning that it might not work (which is what AMO does now, probably because I have ACR installed.) Once installed, I want it treated like any other addon - if an update exists, tell me and let me install it. If the addon stops working because a new FF version changed something the addon relied on, I'll disable or uninstall it. As long as it works, I want updates.

FF can't have it both ways. There's no point to AMO touting the thousands of addons available if half of them are likely to be seen as broken and stop working when a new FF release arrives. Users will get disgusted and go elsewhere, and they'll be right.

[Robert Strong]

On 10/4/2011 11:44 PM, Henri Sivonen wrote:
> On Wed, Oct 5, 2011 at 6:02 AM, Robert Strong<rst...@mozilla.com> wrote:
>> On 10/4/2011 7:58 PM, Will Roberts wrote:

>>> On 10/04/2011 10:37 PM, Robert Strong wrote:
>>>> One concern though is if there is an api change that an extension uses.
>>>> So, when running Firefox 10 in this scenario if extension version 1 is
>>>> compatible with Firefox 10 but not with Firefox 11, extension version 2
>>>> is compatible with Firefox 11 but not with Firefox 10, and the pref is
>>>> set then then they would get extension version 2 when they really want
>>>> extension version 1. I haven't thought this through much so this
>>>> scenario might be incorrect or there might be a way to mitigate this
>>>> from happening.
>>>>
>>>> Robert
>>>>
>>> I believe that's covered in Blair's 2nd point, no?

>> Thank you and it is.
> The point was:

Right and I acknowledged this with "Thank you and it is".

>
>>>>>> * But only when the update's compatibility is for older versions of
>>>>>> the application (if it's only compatible with a newer version of the
>>>>>> application, then the add-on won't be upgraded)

> If extension version 1 is compatible with Firefox 10 and version 2 of
> the extension is compatible with Firefox 11 but not 10, what's the
> plan for making Firefox and the extension update together so that the
> user sees no incompatibility warnings or other unsmoothness?
>

Application update doesn't show an incompatibility warning (or for that
matter other unsmoothness) in the scenario you cited and hasn't since
Firefox 3.6. As for getting extensions to update at the same time as the
application I don't know of any plan though it might be possible to
improve this. Filed https://bugzilla.mozilla.org/show_bug.cgi?id=692159

--
Cheers,
Robert Strong

[Tony Mechelynck]

I'm live-testing trunk SeaMonkey (as my UA string will tell you if you
care to look ;-) ), I have lots of extensions (more than 40 I think, not
counting the disabled ones), and, as someone said before me, the ACR is
my friend. But I don't trust it blindly:

Not getting auto-updates for extensions whose maxVersion are below what
I'm currently using may seem a little awkward, but IMHO it's normal
(I'll explain why near the bottom of this post). I work around it by
having the following two URLs bookmarked:
https://addons.mozilla.org/en-US/seamonkey/extensions/?sort=updated&unreviewed=on
https://addons.mozilla.org/en-US/seamonkey/themes/?sort=updated&unreviewed=on
and visiting them once a day as I get ready to (manually) upgrade to the
next nightly. If there is an update for an addon I already have, or one
whose functionality seems interesting, I go to the individual addon
page, scroll all the way down and unfold the "Versions" foldout (why the
h??? couldn't they leave it displayed as in the previous version of the
AMO stylesheet?): if it supports a not-too-old version of SeaMonkey
(e.g. aurora), or any version of SeaMonkey together with the latest
trunk build of Firefox or Thunderbird, I take my chances and install it
(and check at the next startup how it actually works, and disable or
downgrade it if I don't like what I see). But I wouldn't want anything
to update itself behind my back to a new version which, according to its
maintainers, does not even support the build I'm on.

Best regards,
Tony.
--
There is no distinctly native American criminal class except Congress.
-- Mark Twain

[Tony Mechelynck]

On 05/10/11 04:30, Robert Strong wrote:
> +1 - it really should behave this way though when doing a rewrite or
> coming up on a release it is the right move to not make the change since
> it could introduce regressions.

AMO already auto-updates the maxVersions of extensions which pass some
tests, meant to avoid regressions; those which fail the same tests (and
in particular those which, like the Lightning calendar extension for
Thunderbird and SeaMonkey, include binary XPCOM, or those which use an
API which will soon be removed) don't get the maxVersion bump. IMHO the
ACR shouldn't auto-update extensions which, despite this AMO maxVersion
bumping, don't support the current app version even after the update:
such updates can and may be installed manually, but IMHO it is the
user's full responsibility to decide whether (s)he wants to take the
chance to update to that still-not-officially-supported version of this
or that addon. To that end, (s)he can visit the AMO pages sorted by last
update date, and then decide which updates (s)he wants to install.
Similarly, for addons not hosted at AMO, (s)he can visit each addon's
home site, but of course those off-AMO addons won't be found all in one
place.

Best regards,
Tony.
--
"I'd love to go out with you, but I've been scheduled for a karma
transplant."

[Laurence Durant]

Glad this is getting noticed. I've been running Aurora for day to day browsing since its inception and have been noticing my addons not always updating along with everyone else (wasn't sure if it was just me). I have a dozen addons, so keeping up with them all manually isn't really a long term proposition.

As a side note, I've run the ACR all the while and haven't really had any issues with incompatible addons, so from my point of view the move to make Addons compatible by default is a good choice.

I agree with the view that updated versions of Addons are, by and large, better than staying on older versions. At the very least, I can't think of any deal breaking reason why staying on older versions would be advisable.

[Laurence Durant]