Add-on Sync doesn't respect Add-On Channel Selection

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
7 years ago
2 years ago

People

(Reporter: pwd.mozilla, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sync:addons])

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120210 Firefox/13.0a1
Build ID: 20120210031150

Steps to reproduce:

Sync should respect whether a user is on a development channel or whether a user is on the release channel. Currently it simply assumes that users are on the release channel.
(Reporter)

Updated

7 years ago
Depends on: 534956
Component: General → Firefox Sync: Backend
QA Contact: general → sync-backend
gps: The decision of development vs. release channel is made by AMO in the update service by looking at whether the user's current version is on the devel channel.

Comment 2

7 years ago
AMO sync works by sharing the add-on public ID. When the receiving client receives an add-on record, it performs an AMO search for that ID. That search (typically) yields an install object/URL, which is then downloaded and installed.

I would think that the add-on search would yield the appropriate version of the add-on depending on the client's version. Actually, this is a feature, since Sync does not want to deal with version compatibility. Do the AddonRepository search APIs not adhere to the proper channel by default?
This is about dev vs. release channels for the add-on, which are totally separate from the Firefox version. For example, the current version of Firebug is 1.91, but their development channel is on 1.9b1 (it's behind since a new Firebug was recently released).

I don't think the search api will ever return development channel results. It may be better to use the update service.
(Reporter)

Comment 4

7 years ago
Was a consensus reached over whether or not this would be possible?

Comment 5

7 years ago
We need more technical details before considering this. Can someone point to technical docs on how add-on channels work, specifically how this information is extracted and used.

Presumably Sync would be adding or modifying data in the add-on record which denoted which channel an add-on is on. What should Sync do in the scenario where the requested channel is not available for the current application version? Should Sync try to fall back and install a "more stable" channel?

You may want to read https://wiki.mozilla.org/Services/Sync/Addon_Sync for considerations Sync has when dealing with add-ons and why this may not be a trivial feature to do right.
As I understand the add-on channels stuff (which isn't very well as it is entirely AMO side), then you'd have to sync the add-on version number as well as the ID to make it work correctly
andym knows about the update service.
(Reporter)

Comment 8

7 years ago
(In reply to Gregory Szorc [:gps] from comment #5)
> What should Sync do in the scenario
> where the requested channel is not available for the current application
> version? Should Sync try to fall back and install a "more stable" channel?

Install as per normal (user chosen channel, in this case development) and disable would be my suggestion.
(Reporter)

Comment 9

6 years ago
Any thoughts on this andym?

Comment 10

6 years ago
The update service keeps users on the beta channel by only giving them the beta version. If there's no beta update, we don't give them an update. There's a couple of wrinkles in there when installed addons are pending review and so on.

The update service currently requires only: the application ID, application version and addon guid (and reqVersion but it looks like we ignore that).

Using update for sync to figure out what addon to sync would make sense to me since it also contains the: default to compatible logic, channel logic and so on. This would keep sync in line with what users see in the get addons pane.
(In reply to Andy McKay [:andym] from comment #10)
> Using update for sync to figure out what addon to sync would make sense to
> me since it also contains the: default to compatible logic, channel logic
> and so on. This would keep sync in line with what users see in the get
> addons pane.

You are going to have to spell that out for me in terms of API calls. Sync is using AddonRepository now. What does it need to use?

https://hg.mozilla.org/mozilla-central/file/default/services/sync/modules/engines/addons.js

Comment 12

6 years ago
I don't know the location of the API in Firefox. However it hits the URL defined at extensions.update.url and extensions.update.background.url (you can see these in about:config).

For example:

https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

For example, here's a check:

/update/VersionCheck.php?reqVersion=2&id={e968fc70-8f95-4ab9-9e79-304de2a71ee1}&version=0.7.3&maxAppVersion=13.*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=16.0a1&appOS=Darwin&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=16.0a1&updateType=97&compatMode=normal
(Reporter)

Comment 13

6 years ago
Does that mean that Firefox should simply append "&channel=%CHANNEL%" to the URL?
Greg: is this actionable? Resolved?
Flags: needinfo?(gps)
Whiteboard: [sync:addons]
(Reporter)

Comment 15

6 years ago
GPS?
(Reporter)

Updated

2 years ago
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
Version: unspecified → Trunk
Hi Andy! I'm curious how this will work in the Web Extensions-only world. Are there separate development channels we need to consider, and will we still need to switch to the update service?

(For that matter, are there special considerations for Sync that we need to keep in mind when Firefox transitions to Web Extensions? What happens to a user's synced add-ons once they upgrade to 57?)
Flags: needinfo?(amckay)

Comment 18

2 years ago
AMO does still have seperate development channels, called "beta". There is a plan to remove them at some point in the future and I don't think its worth worrying about this bug.

WebExtensions are just add-ons there are no other changes that I think are relevant.

With Firefox 57, we will just disable all add-ons that do not meet the criteria (see https://wiki.mozilla.org/Add-ons/Firefox57) in the client. Whilst sync might still happen on disabled add-ons they won't get loaded by Firefox.
Flags: needinfo?(amckay)
(In reply to Andy McKay [:andym] from comment #18)
> With Firefox 57, we will just disable all add-ons that do not meet the
> criteria (see https://wiki.mozilla.org/Add-ons/Firefox57) in the client.
> Whilst sync might still happen on disabled add-ons they won't get loaded by
> Firefox.

Worth noting that the enabled state is synced, and so this will disable addon for sync users that have any device with version 57.
(In reply to Thom Chiovoloni [:tcsc] from comment #19)
> (In reply to Andy McKay [:andym] from comment #18)
> > With Firefox 57, we will just disable all add-ons that do not meet the
> > criteria (see https://wiki.mozilla.org/Add-ons/Firefox57) in the client.
> > Whilst sync might still happen on disabled add-ons they won't get loaded by
> > Firefox.
> 
> Worth noting that the enabled state is synced, and so this will disable
> addon for sync users that have any device with version 57.

We shouldn't be synching the appdisabled state for add-ons which is what we will be using to disable add-ons.
Ah, yep, that's right, my mistake.
You need to log in before you can comment on or make changes to this bug.