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

Status: UNCONFIRMED

(Firefox :: Sync, defect)

Description

[Paul [pwd]]

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.

Comment 1

[Jeff Balogh (:jbalogh)]

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

[Gregory Szorc [:gps]]

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?

Comment 3

[Jeff Balogh (:jbalogh)]

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.

Comment 4

[Paul [pwd]]

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

Comment 5

[Gregory Szorc [:gps]]

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.

Comment 6

[Dave Townsend [:mossop]]

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

Comment 7

[Jeff Balogh (:jbalogh)]

andym knows about the update service.

Comment 8

[Paul [pwd]]

(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.

Comment 9

[Paul [pwd]]

Any thoughts on this andym?

Comment 10

[Andy McKay]

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.

Comment 11

[Gregory Szorc [:gps]]

(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

[Andy McKay]

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

Comment 13

[Paul [pwd]]

Does that mean that Firefox should simply append "&channel=%CHANNEL%" to the URL?

Comment 14

[Richard Newman [:rnewman]]

Greg: is this actionable? Resolved?

Comment 15

[Paul [pwd]]

GPS?

Comment 16

[Gregory Szorc [:gps]]

I have no clue what comment #12 means. Again, you are going to have to spell this out for us.

See https://hg.mozilla.org/mozilla-central/file/default/services/sync/modules/engines/addons.js#l286 and https://hg.mozilla.org/mozilla-central/file/a4f8cb70cc5d/services/sync/modules/addonutils.js#l213.

Comment 17

[Lina Butler [:lina]]

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?)

Comment 18

[Andy McKay]

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.

Comment 19

[Thom Chiovoloni [:tcsc] (ex-moco)]

(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.

Comment 20

[Dave Townsend [:mossop]]

(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.

Comment 21

[Thom Chiovoloni [:tcsc] (ex-moco)]

Ah, yep, that's right, my mistake.