Admin tool to control alternative add-on recommendations

[jvillalobos]

Issue #4278 introduced an endpoint for the Firefox Add-ons Manager to point to when users are looking for alternatives to their installed legacy add-ons. Now we need this page to actually do something.

For this we need an admin tool that maps add-on ids (the guids, to be precise) to recommended alternatives. Here's what I think we need for the tool:

• Available to AMO users with the Addons:Edit permission.
• Allows to manage mappings between a guid and a URL. So, for example, one mapping would be {d2a46ca0-999d-11da-a72b-0800200c9b57} -> /addon/always-preview-webextension/. This would point users of Always Preview to Always Preview (WebExtension).
• Using the same example as above, visiting /find-replacement/?guid={d2a46ca0-999d-11da-a72b-0800200c9b57} should redirect to /addon/always-preview-webextension/?src=find-replacement. The src argument allow us to track this in add-on download stats.
• The path doesn't need to be an add-on listing. It can also be a category, tag, or collection. Not sure if there's any validation that needs to happen in this field.

If a guid doesn't have a mapping, the default behavior should be to redirect to /collections/mozilla/featured-add-ons/. We've talked about other possible behaviors, like use the add-on's category or tags, but I don't think there has been a strong case given for any of these. @devaneymoz might have other ideas for this.

[devaneymoz]

I think pointing to our main featured collection makes sense. By 1 September this collection will exclusively feature WebExtensions.

[muffinresearch]

@jvillalobos do we have an issue for the actual feature? I'd like to understand the intended end result for the page including UX.

[krupa]

Would it be possible to have one to many correlation? Instead of just one webextension, can i recommend three replacements?

[jvillalobos]

It would be possible to create a collection with multiple replacements and point to that.

[jvillalobos]

@jvillalobos do we have an issue for the actual feature?

If you mean the redirect, no, there's no issue. I just want a simple redirect, nothing fancy. I just created this doc with a bit more detail, including some UX for the management tool, if that helps.

[muffinresearch]

If you mean the redirect, no, there's no issue. I just want a simple redirect, nothing fancy. I just created this doc with a bit more detail, including some UX for the management tool, if that helps.

Ah ok, I misunderstood, I thought this page was going to show something but it's much simpler that that. Thanks for clarifying.

[eviljeff]

@jvillalobos

• if there's no match you just get redirected to the featured collection, right? Is that collection url hard-coded?
• from what I read you want no validation on the input path so you have maximum flexibility. Do you want the path to at least be a valid path on AMO? Or do you want to be able to supply any random URL?

[eviljeff]

random disclaimer - collections have their own src= parameter (and you can't have two) so installs that come from find-replacement via a collection can't be tracked like that.

[jvillalobos]

if there's no match you just get redirected to the featured collection, right? Is that collection url hard-coded?

Yes, this is the URL: https://addons.mozilla.org/firefox/collections/mozilla/featured-add-ons/

from what I read you want no validation on the input path so you have maximum flexibility. Do you want the path to at least be a valid path on AMO? Or do you want to be able to supply any random URL?

The input only takes the path, not the host, so it should always land on AMO. Beyond that, I think it's best to keep maximum flexibility and not worry about validation too much. /find-replacement/ should not be a valid target to avoid redirect loops, though.

collections have their own src= parameter (and you can't have two) so installs that come from find-replacement via a collection can't be tracked like that.

Good observation. At least we can use the visits to collections with src=find-replacement to try to measure things.

[muffinresearch]

Testing steps (stage):

1. Add a replacement for an installed legacy addon in the admin at https://addons.allizom.org/en-US/admin/staff-models/addons/replacementaddon/
2. In the browser set extensions.legacy.enabled to false.
3. Go to addons list in the browser, click the find replacement link - change the host from production to https://addons.allizom.org/ and run the link on stage. You should see the replacement you specified.
4. If a replacement isn't available you should see https://addons.allizom.org/firefox/collections/mozilla/featured-add-ons/

[ValentinaPC]

Verified this on -stage using FF56(Win 7).

• used legacy add-ons with different format for ID (mail, jetpack, UUID ) - "Find replacement" button works as expected.
• tried using a RTL build - works as expected
• tried setting the replacement link to a non-en locale - works as expected

Screenshots and videos:

@muffinresearch : If there is anything else that should be checked here, please let me know. Thanks!

[muffinresearch]

^ @eviljeff - anything else that needs testing here?

[eviljeff]

I think that's all

[ValentinaPC]

@muffinresearch : I think that, maybe, because of the changes from Admin Tools and the VPN implementation, the "Find replacement" option is no longer working as explained above....for me is not working at all.

• I've added a replacement for an add-on in stage using this page: https://addons-internal.stage.mozaws.net/en-US/admin/staff-models/addons/replacementaddon/ but, while accessing the button from about:addons Legacy Extensions tab I am redirected to the featured collection.
  Is my supposition correct or I did something wrong?

[muffinresearch]

@ValentinaPC the browser doesn't know what host you're pointing at, so it will always hit production for the replacement if you use the button in about:addons - I don't think there's a pref to change that. You'll need to try create the url manually to test it rather than hit the button.

[ValentinaPC]

@muffinresearch : I did this: "Go to addons list in the browser, click the find replacement link - change the host from production to https://addons.allizom.org/ and run the link on stage. You should see the replacement you specified." - but still not redirected as expected, as before the VPN change.

[muffinresearch]

The previous instructions only worked before the replacement tool was in production. Now to test in stage:

• Add a new guid + replacement to stage via the replacement tool.
• Go to https://addons.allizom.org/find-replacement/?guid=[GUID_YOU_WANT_TO_TEST]
• Check it redirects to where you expect it to.

[MarkCSmith]

Sorry to comment on a closed issue,but are there docs for this feature? My specific question is whether add-on authors will be able to configure a recommended WE replacement for their own legacy add-on, or if they will need to ask someone at Mozilla to do that for them.

[muffinresearch]

@MarkCSmith hi, this feature is only for admins to setup replacements. There is a discourse thread can contribute suggestions: see https://discourse.mozilla.org/t/favorite-webextensions/17087

[FixitmanArizona]

OR... how about making sure the browser works with all old extensions before updating it. For instance, if the original Google Toolbar. PrefBar, x-notifier, NoSquint, Status4Ever, and TabMixPlus do not work, or have built in replacements that look and work EXACTLY like the legacy extensions, do not release the new version, instead, modify an older version to have the same standards as the new browser would have. Preferably, roll back the browser versioning to before the rapid release madness, and re-release version 3 or 4, and DO NOT allow anyone to use any browser version above 5 until this is fixed. If you're going to completely screw up Firefox, it's not Firefox any more, call it something else, maybe Mozilla Browser, and start fresh. You could then use the Chromium engine in it like Vivaldi or just shut the project down and let Vivaldi do your job for you.