Notify user of missing mozAddonManager

[chuckharmston]

@fzzzy will be removing the non-mozAddonManager paths with this release. Since those APIs have specific prerequisites, including an about:config pref, we may see some mysteriously broken behavior like that experienced this morning if any of those prerequisites are not hit.

To remediate, we should check for the existence (!!navigator.mozAddonManager should suffice) on startup, notify the user if any of them are not met, and suggest steps for fixing it.

I'd suggest the following logic to determine messaging.

1. window.location.protocol === 'https'
   • If not, tell the user to make sure they are accessing on that protocol.
2. Firefox version is >= 49 47 (double-checking that that's when mozAddonManager shipped.
   • If not, tell the user to update.
3. !['example.com', 'testpilot.dev.mozaws.net', 'testpilot.stage.mozaws.net'].includes(window.location.host)
   • If not, tell the user that they need to set extensions.webapi.testing.
4. window.location.host !== 'testpilot.firefox.com'
   • If not, tell the user that they must access Test Pilot on an approved hostname.
5. Tell the user that they should file a bug because we have no idea what's going on.

It is very likely that this is only seen on dev or stage, but there's no reason to not build this to be something that we're comfortable shipping on production. When bug 1359837 lands, there's a very reasonable way production users may run into this. To accommodate, we should also disable the install button with appropriate messaging.

[fzzzy]

Not this release -- the old code is still in place for now. But I will remove the old path fairly soon.

[fzzzy]

@chuckharmston If you have some time this sprint, do you feel like doing this? It should be really straightforward.

[chuckharmston]

See this bug for another place where mozAddonManager may be prevented in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=1359837

[ghost]

If a user has the pref mentioned in bug 1359837 flipped, they'll see an install dialog followed by an error message here. The biggest use case for that pref is managed workstations who have admins who flip it.

marking needs UX for how we want to communicate to the user and cc @johngruen . This feels like a pretty slim audience (@chuckharmston is asking about how many people were talking about) but this issue is blocking landing the patch in the bug.

edit: didn't mean to close

[fzzzy]

Time to get going on this soon.

[johngruen]

Will bring it up in the UX meeting; no reason we can't crank something out ASAP

[fzzzy]

@johngruen Since this will only be seen by a small number of users that try to test Test Pilot locally, on stage, or on dev, but have something misconfigured, I don't think much UX is required. I did a simple implementation, here are examples of what it looks like in various error cases:

[flodolo]

As asked in the past, please ping when there are pull requests with strings (plus #2532)

[fzzzy]

@flodolo Sorry about that. We will work on setting up a localization branch next quarter so this process is more formalized.