Closed Bug 701631 Opened 13 years ago Closed 11 years ago

Addon maxVersion is ignored during upgrade for non-native extensions (type 2), requiring -safe-mode later on

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
blocker

Tracking

()

RESOLVED INVALID

People

(Reporter: haqer, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

I was not able to reproduce this by starting from scratch, but it happened at least once for me.
1. I had the following lang pack addon's 7.0 version on Firefox 7:
https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/
This addon is per-release: it's almost certain to require an upgrade for the next release, although sometimes it can still be used if the UI changes are only visible upon certain menu selections, and user doesn't go to those UI components.
2. I selected Apply Update (to 8.0) from About...


Actual results:

3. I got the addon compatibility dialog, but IIRC, the addon wasn't disabled due to incompatibility automatically, and allowed to continue with it enabled.
4. Since some UI changes in Firefox 8 are very visible, continuing led to an XML parsing error, and browser (profile) became unusable. I had to use -safe-mode to update the addon to its 8.0 version, before i could use that profile.


Expected results:


The browser should have displayed "Will be enabled when compatible", and made sure that the incompatible version of the addon is not enabled when running using the upgraded code.

P.S. As i mentioned. I tried installing the addon from scratch on 7.0, and then upgrading it to 8.0, but then everything worked OK in Firefox and Thuderbird. However, at least in 1 profile, and i believe the same happened in a 2nd profile, the 7.0 version of the addon that was installed a while ago, was not disabled due to incompatibility. In profile 1, it led to parsing error as mentioned above. In profile 2, i think i encountered the same "enabledness" situation, but i decided to not continue, and first uninstall it, then reinstall it for reliability. But as i mentioned, when installing addon's 7.0 version just before upgrading Firefox to 8.0, i didn't encounter any issues.
P.P.S. I'm not sure what could be going on, but can think of 2 possibilities:
A. Firefox didn't check maxVersion right (either locally or remotely) for whatever reason: connectivity, threading, IO, etc. This seems less likely than B. below, but if we find out that there's no caching of maxVersion, then this item A. could be left as the root cause.
B. I am not 100% sure whether AMO automatically updated maxVersion for this addon's version 7.0 to 8.0: on the one hand, i haven't found any notification indicating that in my Inbox, on the other hand in AMO account i'm seeing an activity saying "Application max version for Version 7.0 updated." ("1 month ago by Mozilla"). It doesn't mentioned what it was updated to, but the only thing it would make sense for it to be updated to is 8.0, or 9.0, or higher. It also shows that i updated it 4 days and 5 hours ago: the only thing i could have updated it to is back to the original 7.0 version (unless AMO could have also saved a noop change, from 7.0 to 7.0, in the activities). It appears quite possible that AMO updated it to 8.0 a month ago, and despite me changing it back to 7.0 4 days ago, at least 1 Firefox upgrade made 2 days ago didn't respect the correct maxVersion. In short, the second possibility is that Firefox cached the maxVersion value sometimes in the [1 month ago, 4 days and 5 hours ago) timespan, and used it 2 days ago.
P.P.P.S. I hope this bug sheds some light on the situation and/or i and nobody else encounters this issue again. The worst thing that could happen is that this is a hard-to-reproduce bug (and caching or, especially, threading could be in that category), and nobody pays attention to it, while some users continue to run into this issue. I just want to make sure this worst-case scenario is avoided.
It is very likely to be B, see bug 688980
(In reply to John P Baker from comment #1)
> It is very likely to be B, see bug 688980

Perhaps the auto-bump for lang packs was done on 10/10 or 10/11, etc., and the auto-bump for lang packs got abandoned on 10/13. If that's the case, and it really happened due to B., then we this issue shouldn't occur again for Firefox 9 and beyond?

P.S. I think 6-week release idea got rushed. This should have evolved more slowly (maybe 4 months, 3 months, etc.), and it would have gone more gracefully. And even then, it still appears too fast for the long term.
I encountered the same issue when upgrading from Firefox 16.0.2 to Firefox 17.0, on both Windows XP (pre-existing profile with the addon installed a day or 2 before 17.0 release) and Linux (brand new profile initialized with Firefox 16.0.2 (for troubleshooting) with the addon installed just before upgrading to 17.0 (after 17.0 release)). The most important difference from the OP is in the item 3. below. The conclusion is in the last paragraph preceding note [1].

Updated steps to reproduce:

1. I installed the following lang pack addon's 16.0 version on Firefox 16.0.2:
https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/
This addon is per-release: it's almost certain to require an upgrade for the next release...
2. I selected Apply Update (to 17.0) from About...


Actual results:

3. I did not get the addon compatibility dialog at all (when tested on Linux Firefox did NOT make any requests to check addon's version[1] and continued with it enabled, even though it always had maxVersion of 16.* (which is not compatible with 17.0)).
4. Since some UI changes in Firefox 17 are very visible, this led to an XML parsing error, and browser (profile) became unusable. I had to use -safe-mode arg to the firefox command to update the addon to its 17.0 version, before i could use that profile.


Expected results:

The browser should have displayed "Will be enabled when compatible", and made sure that the incompatible version of the addon is not enabled when running using the upgraded code.

Based on item 3., i'm concluding that neither A. nor B. from the OP, nor bug 688980 is an issue here. The issue in this case apparently is that the application did not honour the addon's maxVersion, and also did not make any requests to check whether any updates are available. This might not be a serious issue for many addons, but for some addons it makes the profile unusable until and unless the user (if they are aware of this feature and geeky enough) starts the app with -safe-mode arg, and updates the addon using Ctrl+Shift+A and then Check for Updates).

[1] Something like this would be expected, but no such request was made: https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id={d5af7e07-9f33-40c7-9234-0b2c2da6ada2}&version=16.0&maxAppVersion=16.*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=17.0&appOS=Linux&appABI=x86-gcc3&locale=tr&currentAppVersion=16.0.2&updateType=98&compatMode=normal

P.S. I'm surprised that this is happening for the 2nd year in a row in November, and i've not had any such issues in any other month, but i'm not sure whether that's just a coincidence.
P.P.S. Given easy reproducibility, and severe impact, can this be escalated all the way to make it be fixed with the next minor update?
Severity: normal → critical
OS: Windows XP → All
Hardware: x86 → All
Version: 8 Branch → Trunk
More troubleshooting info:
a. The same issue encountered when upgrading from Thunderbird 16.0.2 to Thunderbird 16.0.
b. The issue is not encountered when upgrading from Firefox 15.0.1 to Firefox 17.0; addon compatibility dialog is shown, and the following request is made:
https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id={d5af7e07-9f33-40c7-9234-0b2c2da6ada2}&version=15.0&maxAppVersion=15.*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=17.0&appOS=Linux&appABI=x86-gcc3&locale=tr&currentAppVersion=15.0.1&updateType=98&compatMode=normal
b.1. The addon's version 15.0 was type 8, and i was required to change it to type 2, but i don't think it matters here: Firefox shouldn't ignore maxVersion for either type 2 or type 8.
b.2. I'm suspecting the addon manager has had some changes between releases 15 and 16 that could be causing this.
Summary: Sometimes addon maxVersion appears to be ignored during upgrade, requiring -safe-mode later on → Sometimes addon maxVersion is ignored during upgrade, requiring -safe-mode later on
Another confirmation of this issues using a more usual extension addon:
i. Install Firefox 16 (i used 16.0.2)
ii. Start Firefox 16 using a new profile (i used firefox --ProfileManager to make one just for troubleshooting this)
iii. Install
https://addons.mozilla.org/en-US/firefox/addon/blend-in/versions/?page=1#version-16.0.1
on Firefox 16 on the new profile
iv. Restart the app
v. Open Help->About dialog, and let it download the update, and then apply the update, and restart

Actual results:
Even though Blend-in 16.0.1 has a maxVersion of 16.*, and has never had a higher version than that since the new profile has been made, Firefox does not make any version check HTTP requests while updating from Firefox 16 to Firefox 17, and doesn't disable the installed version 16.0.1 of the addon (despite it not being compatible with Firefox 17): in this case this results in JS errors in the Error Console, and the addon not functioning (which the users won't be aware of unless they verify it themselves).


Expected results:
I. Since Blend-in 16.0.1 has a maxVersion of 16.* and is not compatible with Firefox 17, at a minimum the installed version 16.0.1 of the addon MUST be disabled until an update compatible with Firefox 17 is installed (and if there's no compatible update available then in this use-case the addon should be disabled if the user completes the update).
II. Since a newer version of the addon exists, and that version is compatible with Firefox 17, a suggestion must be made to automatically install it (in my experience this is always preceded by a version check HTTP request).

P.S. Both cases are seriously messed up: in the previous case, the UI is broken and the profile is unusable unless the user uses -safe-mode to fix it up; in this case, the user is very likely to not be aware that Firefox is using an incompatible addon without updating it, and that the addon isn't working (if it's a component based addon working behind-the-scene, most users are likely to not notice that it isn't working because of a Firefox bug). It's debatable which one of these cases is "less messed up": to me both are horrible (and more so than "Friday the 13th").
Severity: critical → blocker
(In reply to Reşat SABIQ (Reshat) from comment #4)
> More troubleshooting info:
> a. The same issue encountered when upgrading from Thunderbird 16.0.2 to
> Thunderbird 16.0.
Of course, i meant "from Thunderbird 16.0.2 to Thunderbird 17.0."

> b.2. I'm suspecting the addon manager has had some changes between releases
> 15 and 16 that could be causing this.
Well, now that i checked this out using Blend In addon as, i actually remember this happening on at least 1 other occasion before this upgrade: i'm not sure when, but as a very rough interval it was 6-to-18 months ago. So while checking recent changes might be useful, perhaps the bug has been present in Firefox for quite some time.
The same issue is still happening when upgrading to Firefox 18 (for the afore-mentioned addon examples):
1. https://addons.mozilla.org/en-US/firefox/addon/blend-in/versions/17.0
2. https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/versions/17.0
Another detail, during upgrade involving 1. on Windows, after getting back into the profile using -safe-mode, i took a few minutes thinking before clicking on Check for Updates from Ctrl+Shift+A: and during those few minutes the addon actually got auto-updated. That's 1 less step to recover the profile: all that needs to happen is auto-updating BEFORE loading the profile (or the very darn least disabling the obviously incompatible (by maxVersion) addons)!
Component: Extension Compatibility → Add-ons Manager
Product: Firefox → Toolkit
The same issue is still happened when upgrading from Firefox 18.0.2 to 19.0.

P.S. Also logged bug 842922, which is probably related in some way.
This issue is happening for type 2 addons (extensions). It is not happening for type 8 addons (lang packs).
Summary: Sometimes addon maxVersion is ignored during upgrade, requiring -safe-mode later on → Addon maxVersion is ignored during upgrade for extensions (type 2), requiring -safe-mode later on
More specifically:
This issue is happening for non-native type 2 addons (extensions). It is not happening for type 8 addons (lang packs), and type 2 addons with binary components.
Summary: Addon maxVersion is ignored during upgrade for extensions (type 2), requiring -safe-mode later on → Addon maxVersion is ignored during upgrade for non-native extensions (type 2), requiring -safe-mode later on
Since you turned your language packs into extensions, the compatibility rules for extensions apply. See bug 842922 comment #4 for the rest of it.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
FYI: I had to open bug 857431 as a follow-up to this issue.
You need to log in before you can comment on or make changes to this bug.