Closed Bug 1488699 Opened 5 years ago Closed 3 years ago

Download appversion-dependent addon updates before applying an app update


(Toolkit :: Add-ons Manager, defect, P2)




Tracking Status
firefox62 --- affected
firefox63 --- affected


(Reporter: flod, Unassigned)


Not exactly sure what's the best formulation for this bug, or if it's a bug on the AMO side of things, but here's the scenario:

1. User is using Firefox 60 with a language page installed.

2. On September 4, he installed an update to 61, and the language pack got disabled.

At this point, language packs on AMO are already compatible with 62 (released on Sep 4), but updates in Firefox are still throttled. 

Should AMO serve a version of the add-on compatible with 61? Or that's a limitation on Firefox's side?
This has been a recurring issue since we started signing language packs as part of the release process.

I can go over the why's and specifics if you like, but tl;dr there is an AMO bug on the symptom of this and it is actively being worked on to reduce the user pain.
Err actually c#1 was slightly offtopic, as the user was coming from Firefox API not AMO website...
For a user with version 60.0buildid20180605171542 installed and running Firefox 61, the update check should request something like this:{ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=61.0&appOS=Darwin&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=61.0&updateType=97&compatMode=normal 

That offers an update to a version of the language pack that is compatible with 61.

:flod can you reproduce this?
Trying to ask Mike, since the report originated from a partner. Maybe there's something else going on.

In the meantime I'll try to see if I can reproduce.
Flags: needinfo?(mozilla)
Maybe 8180 that Callek pointed to fixed this? Resolved yesterday, so this could just be timing?
Based on the partner description, it seems to be the same problem. I've let them know that it's a rare occurrence and should clear up when 62 ships.
Flags: needinfo?(mozilla)
As I understand it, 8180 is about the addons frontend (ie, what is rendered on a particular addon's AMO page).  The API endpoint that Firefox hits to check for updates is a totally separate code path.  Of course they both hit the same underlying database but they have quite different rules for looking at the collection of available versions and deciding what to present, so I doubt there's any connection.
I tried to reproduce, but I end up with bug 1472946.

1) Install 60.0.2 in en-US

2) Starts with a new profile, work offline. Disable signing for langpacks, install Italian langpack, and add intl.locale.requested = 'it' in about:config

Reboot, still work offline. At this point the browser is localized in Italian.

3) Disable Offline mode, stay online for a bit. The browser will get an update (in my case to 62, not 61). The browser restarts with the language pack disabled, saying that it's not compatible with 62.

I need to manually check for updates to find an updated version.

I guess this makes this one a WORKSFORME?
Uh oh, I think this is from bug 1433574.
The reasoning for that bug was that we no longer have extensions that require strict compatibility, but langpacks got overlooked...
Summary: Compatible version of language pack not offered by AMO → Removing the startup addon update check breaks langpacks
We shouldn't restore the startup update check for this, the real solution here is to check for and download updates to addons that are dependent on the app version (which should just be langpacks these days) at the same time we download the app update, rather than after it has been applied.
Priority: -- → P2
Summary: Removing the startup addon update check breaks langpacks → Download appversion-dependent addon updates before applying an app update
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.