AMO thinks addons can be installed in Fenix

[st3fan]

I just saw the following feedback on a Slack channel:

Just installed Fenix, awesome, thanks! I suppose add-ons are not supported (yet?) AMO says add-ons are compatible but none can be installed.

This is probably because we use the exact same UA identification as Fennec:

Fenix: Mozilla/5.0 (Android 9; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0

Firefox Mozilla/5.0 (Android 9; Mobile; rv:65.0) Gecko/65.0 Firefox/65.0

┆Issue is synchronized with this Jira Task

[vesta0]

@cpeterso can we create a different UA for Fenix?

[cpeterso]

The Gecko team does not want GV-powered apps to customize their UA strings. However, AMO uses some privileged JS API (mozAddonManager) to talk to Fennec. The AMO team could use them to differentiate between Fennec and Fenix: no mozAddonManager -> Fenix. I will ask around for an AMO team contact.

[cpeterso]

This Fennec/Fenix detection issue will also affect SUMO because SUMO customizes its KB articles based on the user's OS and browser version. Perhaps we can temporarily use a custom Fenix UA string. After we complete the Fennec->Fenix migration, we can restore Fenix's standard mobile UA. I will talk to the GV team about allowing Fenix to customize the UA string.

AMO and SUMO can differentiate legacy Fennec from Fenix by browser version and the temporary custom UA. Example logic:

Browser Version?	Custom Fenix UA?	Detect Browser As
< 68	N/A	Fennec
== 68	No	Fennec
== 68	Yes	Fenix
> 68	N/A	Fenix

[muffinresearch]

Since AMO is rendered server-side, it would be much better for us to have something in the request to differentiate Fenix rather than have to use a client-side API after the page has loaded. It would be good to understand if there are any alternative options there.

[cpeterso]

Since AMO is rendered server-side, it would be much better for us to have something in the request to differentiate Fenix rather than have to use a client-side API after the page has loaded.

Thanks. That's good to know. I'm still talking with the Fenix and GeckoView engineers about our options. I'll keep you posted.

[cpeterso]

I filed a GeckoView bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1548428

The current proposal is that GeckoView 68 will spoof a special version number (like "68.99" or jump ahead to "69.0") on AMO and SUMO so the sites' server-side UA checks assume:

• version < X is legacy Fennec
• version >= X is Fenix (or some other GeckoView-powered browser)

The exact version number is still being bikeshedded.

[muffinresearch]

@cpeterso I've filed mozilla/addons#13157 to cover checking/updating our add-on compatibility code on AMO once this is solidified.

[reinhart1010]

SeeAlso webcompat/webcompat.com#2859

[cpeterso]

@vesta0 - I removed this issue's blocked and Needs GV work labels. I resolved the GV bug as WONTFIX because Fenix can override the UA on AMO and SUMO itself like FxR does (to auto-request desktop sites):

FxR override issue:
MozillaReality/FirefoxReality#488

FxR override code:
https://github.com/MozillaReality/FirefoxReality/blob/c5f1b17ed8392aff09a1cc252f78f7d01f3fc2bc/app/src/common/shared/org/mozilla/vrbrowser/browser/UserAgentOverride.java

[cpeterso]

In the meantime, the AMO and SUMO teams can proceed with their server-side UA checks for "Firefox Android version >= 69 means Fenix". That check will be valid even if we don't implement a UA override workaround for the overlapping period of Fennec/Fenix 68.

[reinhart1010]

Duplicate: https://groups.google.com/forum/m/#!topic/fenix-nightly/ImcINWPjbB8

[cpeterso]

@vesta0 added this to High priority backlog (not in the current sprint)

@vesta0 - Does High priority backlog (not in the current sprint) mean this issue will be fixed before or after Fenix MVP?

This issue is only relevant while Fenix is using GV 68. There will be no point in fixing this issue after Fenix updates to GV 69.

[vesta0]

@cpeterso looks like GV 69 beta will be available on July 9 so probably won't be able to ship a GV 69 build of Fenix for at least 3 weeks after MVP. @st3fan what do you think about the impact vs risk of not fixing this?

[vesta0]

@mheubusch please review content mentioned above.

[kbrosnan]

https://addons.allizom.org/ is the staging server. If the amo team's code change has been pushed to staging it can be tested there.

[cpeterso]

Looks like SUMO has a staging site, too: https://support.allizom.org/

Fenix's UA spoofing should probably include the AMO and SUMO staging domains.

[willdurand]

addons.allizom.org is the staging server. If the amo team's code change has been pushed to staging it can be tested there.

The patch has not been pushed to stage/prod yet, but it is available in -dev at: https://addons-dev.allizom.org.

[jonalmeida]

Fenix's UA spoofing should probably include the AMO and SUMO staging domains.

I'd prefer not to do this since we don't have a good distinction between what goes in a release/debug app for things like this. Local testing might suffice for now..

addons.allizom.org is the staging server. If the amo team's code change has been pushed to staging it can be tested there.

The patch has not been pushed to stage/prod yet, but it is available in -dev at: https://addons-dev.allizom.org.

Thanks @willdurand ! I've tested this change locally by adding the dev envirionment in a local build and I see the warning message on top. 🎉

[bifleming]

@jonalmeida can this go to QA now?

[jonalmeida]

@bifleming No, I don't believe the production servers for AMO or SUMO have the required changes yet, they are only in the staging right now.

[willdurand]

@bifleming No, I don't believe the production servers for AMO or SUMO have the required changes yet, they are only in the staging right now.

It will land on Thursday for AMO.

[jonalmeida]

This can be closed now, AMO and SUMO both have their changes live. Thanks everyone for fixing this together! 🙂

[abodea]

Verified as fixed on the latest build 7/15 using Samsung Galaxy s10+(Android 9).

[genodeftest]

Is there a tracking bug or roadmap for addon support in Fenix?

[cadeyrn]

mozilla/addons-frontend#574 is about WebExtension support in Fenix, not this issue. ;-)