1260213 - Set extensions.systemAddon.update.url to enable system add-ons infrastructure for Fennec

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

The system add-ons infrastructure that's used to ship Hello and Pocket in Firefox for Desktop is also available to Fennec, and was designed with Fennec as a potential consumer.

Apparently, in order for a system add-on to be shipped for Fennec, it's necessary to point extensions.systemAddon.update.url at an appropriate URI endpoint that advertises potential updates to system add-ons. If the pref is not set, XPIProvider.jsm assumes that system add-ons are not being used.

Desktop sets this to https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml, and I wonder if that's sufficient for Fennec as well.

The reason why I'm advocating the enabling of this infrastructure is for the FlyWeb team, who are hoping to ship some experimental UI for FlyWeb (preffed off by default to start). This allows them to focus on developing the UI while keeping it isolated from the Fennec core front-end team.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey Mossop, how was the endpoint that serves up https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml for desktop set up, and do you think we'd need to do anything special for Fennec? Or can we just point Fennec at this and close this out?

Comment 2

[Dave Townsend [:mossop]]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #1)
> Hey Mossop, how was the endpoint that serves up
> https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/
> %BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/
> %DISTRIBUTION_VERSION%/update.xml for desktop set up, and do you think we'd
> need to do anything special for Fennec? Or can we just point Fennec at this
> and close this out?

Not sure, does OS_VERSION allow us to distinguish between Firefox and Fennec? Bhearsum can probably help better here.

Comment 3

[[e-mail] (:bhearsum)]

(In reply to Dave Townsend [:mossop] from comment #2)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #1)
> > Hey Mossop, how was the endpoint that serves up
> > https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/
> > %BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/
> > %DISTRIBUTION_VERSION%/update.xml for desktop set up, and do you think we'd
> > need to do anything special for Fennec? Or can we just point Fennec at this
> > and close this out?
> 
> Not sure, does OS_VERSION allow us to distinguish between Firefox and
> Fennec? Bhearsum can probably help better here.

Technically yes...but it's probably not a good way of doing it. The kindof filtering we have on OS Version is designed to deal with OS deprecation, not routing requests -> responses. There's two better ways of doing this:
1) Use a unique %PRODUCT% (eg: FennecSystemAddons). This would mean we have a parallel set of rules/releases for Fennec.
2) Use the same product, but distinguish by %BUILD_TARGET%. Balrog delegates %BUILD_TARGET% into the Releases, so you can do platform-specific things in there. Eg, this is the current SystemAddons blob we're using to ship Loop: https://gist.github.com/bhearsum/9fe0b8b99392008ef377. We could change these Releases to have all of the Fennec+Firefox SystemAddons, and use the Build Targets to ship the right things to the right apps.

I'd recommend #2 if we expect that Firefox and Fennec are going to ship System Addon updates at the same time. If not, the parallel set of rules makes it much easier to ship per-app SystemAddon updates.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Talked to bhearsum IRL, and #2 sounds like a fine choice to start with.

TL;DR, putting https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml as the value for extensions.systemAddon.update.url in mobile.js should be fine.

Comment 6

[Robert Helmer [:rhelmer]]

The system add-on update check happens as part of AddonManagerPrivate.backgroundUpdateCheck(), which Fennec does run:

https://searchfox.org/mozilla-central/source/mobile/android/components/AddonUpdateService.js#51

I ran into a snag after setting the extensions.systemAddon.update.url because currently system add-on updates depend on the app.update.enabled pref being set:

https://searchfox.org/mozilla-central/rev/e3cba77cee3ff1be38313abe9c804d13c51bd95b/toolkit/mozapps/extensions/AddonManager.jsm#1507

The check fails before this though in the hotfix code, since it's checking for the non-existent app.update.auto pref:

https://searchfox.org/mozilla-central/rev/e3cba77cee3ff1be38313abe9c804d13c51bd95b/toolkit/mozapps/extensions/AddonManager.jsm#1363

Since the old-style hotfix works in Fennec production builds presumably this is only an issue when testing with local builds though. I'll test that this is true and also that system add-on updates actually work (I would expect that they do since that's all done on the gecko side)

Comment 7

[Robert Helmer [:rhelmer]]

Attachment: Bug 1260213 - enable system add-on updates for Fennec

Review commit: https://reviewboard.mozilla.org/r/215412/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/215412/

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8945167 [details]
Bug 1260213 - enable system add-on updates for Fennec

https://reviewboard.mozilla.org/r/215412/#review221330

Comment 9

[Robert Helmer [:rhelmer]]

Attachment: screen shot showing system add-on update on fennec

I just tested this locally and was able to install a system add-on update in the emulator using the webserver on my host, lgtm.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1447c185cfb3
enable system add-on updates for Fennec r=snorp

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/1447c185cfb3

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

This sounds great. 

I would like for it to have a little manual QA so we have verification that the system is working. We could file a PI request for this, and ask for testing across a few devices and Android versions.

Comment 13

[Andrei Bodea[:andrei]]

Hello,

I've re-tested this issue checking that the add-ons are installed and there are no errors displayed in the console.
Every add-on installed was correctly displayed in about:support with name, version, enabled and ID, no errors were displayed.

Also, I checked the value for extensions.systemAddon.update.url and it had the following URL:
https://aus5.mozilla.org/update/3/SystemAddons/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml.

@Robert I don't have access to set up a test URL and maybe you can help me regarding this in order to test this issue properly.

I checked this issue on the following devices and builds:
Devices:
Samsung Galaxy S8+ (Android 8.0.0)
Samsung Galaxy S7  (Android 7.0)
Samsung Galaxy S6 (Android 6.0.1)
Sony Xperia Z3	(Android 5.1.1)

Builds:
Nightly 62.0a1
Beta 61.0b9
Release 60.0.1

Thank you,
Andrei