Support installation of Recommended Extensions from AMO

[jvillalobos]

What is the user problem or growth opportunity you want to see solved?

Installation of add-ons from AMO, for those add-ons that are currently supported on Fenix by default. This is currently handled via collections, but AMO has a Recommended Extensions for Fenix list which is what we want to use as the source of truth moving forward.

How do you know that this problem exists today? Why is this important?

AMO gets significant traffic from mobile browsers and we want it to support basic navigation and installation of the same extensions that are currently supported by default.

Who will benefit from it?

Fenix users who look for add-ons to install on AMO rather than the Add-ons Manager.

┆Issue is synchronized with this Jira Task

[csadilek]

Current plan is to implement this via deep links:

• AMO would have to add (fenix://) links including the ID of the recommended add-on to install
• Fenix would:
  • Verify that request comes from AMO
  • Verify that add-on is in list of recommended add-ons
  • Trigger installation via Add-ons Manager

Update:

While this will be similar to deep links (use a custom URI e.g. fenix-addons), we should likely not use our "deep link" functionality for this, because it results in different schemes per release channels (fenix-beta://, fenix-nightly://) which would make this impractical for AMO.

Instead we can use our interceptor, verify the triggerUri and handle it there directly.

[brampitoyo]

@csadilek I’ve updated the Miro document to account for this upcoming AMO support.

User flow: https://miro.com/app/board/o9J_kw8Lt8g=/?moveToWidget=3074457351173371580&cot=10

Mockups: https://miro.com/app/board/o9J_kw8Lt8g=/?moveToWidget=3074457349916418330&cot=14

As we’ve discussed a couple of weeks back, user-facing changes will be minor:

1. People will be able to visit and/or search the AMO website in multiple ways:
   • Fenix address bar → type keywords → search engine results page → AMO
   • Fenix address bar → type URL → AMO
   • Fenix Add-ons Manager → “Find more add-ons” button → AMO
   • Fenix Add-ons Manager → “Search addons.mozilla.org” search box → AMO
2. People will be able to install add-ons by tapping the “+ Add to Firefox” button on the AMO website
   • In addition to installing via the Fenix Add-ons Manager – a feature we already support today

This will solve a major user problem: many people find add-ons through search engines and the AMO website, but couldn’t install it there.

It will also future-proof the Fenix Add-ons Manager for the foreseeable future. The Manager will focus on showing a curated list of ≤30 recommended and/or verified add-ons. The rest of our catalogue will be listed and installed on AMO.

[csadilek]

Thank you @brampitoyo! For the scope of this ticket, and as a first step, we just want to be able to install recommended add-ons via AMO by re-directing to Add-ons Manager and triggering our existing native UI. The other Add-ons Manager enhancements ("Find more" and "Search") will be implemented later.

[csadilek]

Update: We won't be making any changes on AMO for this. Instead, we will intercept the https links already on AMO (Add to Firefox) and trigger the logic described above. The links contain the file ID of the add-on which can be used to map to the add-on from our collection.

See also: mozilla-mobile/android-components#8938

Example link for uBlock: https://addons.mozilla.org/android/downloads/file/3663488/ublock_origin-1.30.6-an+fx.xpi

[brampitoyo]

@csadilek Thanks! I’ve updated the user flow to suit this new approach.

Fenix will intercept AMO’s link and check whether the add-on’s file ID that AMO gives us matches our own list of local add-ons.

[eliserichards]

We should only allow web requests, so that users can't construct their own requests.

[csadilek]

Required functionality in Fenix landed. Let's leave this open until we can activate functionality on AMO.

[andreicristianpetcu]

Is there a bug tracking the AMO side? @csadilek

[willdurand]

Is there a bug tracking the AMO side? @csadilek

I think it is: mozilla/addons#13892. The feature should be enabled on AMO -dev already.

[lobontiumira]

Hi all,
We've verified this with "Search by Image" add-on on Firefox Beta 85.0.0-beta.7 using the following devices:
• Google Pixel 3a (Android 11), and
• Google Pixel (Android 10).
Thanks!

[AndiAJ]

Hi, verified as fixed with "Search by Image" on 85.1.0-rc.1 using the following devices:
• Samsung Galaxy Tab S6 (Android 10)
• OnePlus A3 (Android 6.0.1)

[willdurand]

Note: I built a debug APK with the following patch for AMO QA:

diff --git a/app/build.gradle b/app/build.gradle
index c94ec8c59..933a11a99 100644
--- a/app/build.gradle
+++ b/app/build.gradle
@@ -37,7 +37,9 @@ android {
         testInstrumentationRunnerArguments clearPackageData: 'true'
         resValue "bool", "IS_DEBUG", "false"
         buildConfigField "boolean", "USE_RELEASE_VERSIONING", "false"
-        buildConfigField "String", "AMO_COLLECTION", "\"7dfae8669acc4312a65e8ba5553036\""
+        buildConfigField "String", "AMO_URL", "\"https://addons.allizom.org\""
+        buildConfigField "String", "AMO_COLLECTION_USER_ID", "\"11686491\""
+        buildConfigField "String", "AMO_COLLECTION", "\"fenix\""
         def deepLinkSchemeValue = "fenix-dev"
         buildConfigField "String", "DEEP_LINK_SCHEME", "\"$deepLinkSchemeValue\""
         manifestPlaceholders = [
diff --git a/app/src/main/java/org/mozilla/fenix/AppRequestInterceptor.kt b/app/src/main/java/org/mozilla/fenix/AppRequestInterceptor.kt
index 063a73cf2..7b3aeb1fb 100644
--- a/app/src/main/java/org/mozilla/fenix/AppRequestInterceptor.kt
+++ b/app/src/main/java/org/mozilla/fenix/AppRequestInterceptor.kt
@@ -168,7 +168,7 @@ class AppRequestInterceptor(
     companion object {
         internal const val LOW_AND_MEDIUM_RISK_ERROR_PAGES = "low_and_medium_risk_error_pages.html"
         internal const val HIGH_RISK_ERROR_PAGES = "high_risk_error_pages.html"
-        internal const val AMO_BASE_URL = "https://addons.mozilla.org"
+        internal const val AMO_BASE_URL = "https://addons.allizom.org"
         internal const val AMO_INSTALL_URL_REGEX = "$AMO_BASE_URL/android/downloads/file/([^\\s]+)/([^\\s]+\\.xpi)"
     }
 }
diff --git a/app/src/main/java/org/mozilla/fenix/components/Components.kt b/app/src/main/java/org/mozilla/fenix/components/Components.kt
index e4f721cfc..7f95cd580 100644
--- a/app/src/main/java/org/mozilla/fenix/components/Components.kt
+++ b/app/src/main/java/org/mozilla/fenix/components/Components.kt
@@ -97,6 +97,8 @@ class Components(private val context: Context) {
             AddonCollectionProvider(
                 context,
                 core.client,
+                serverURL = BuildConfig.AMO_URL,
+                collectionUser = BuildConfig.AMO_COLLECTION_USER_ID,
                 collectionName = BuildConfig.AMO_COLLECTION,
                 maxCacheAgeInMinutes = DAY_IN_MINUTES
             )

I am thinking about contributing the BuildConfig part back because that'd be simpler to build Fenix for AMO -dev or -stage in the future (which we need now that there is a tight integration between AMO and Fenix). I also think that the AMO_BASE_URL should be a build config variable.

Our QA was able to fully verify the AMO/Fenix install flow with AMO -stage.

See: mozilla/addons#13892