Closed Bug 1524085 Opened 1 year ago Closed 1 year ago

Ship intervention to fix Amazon Prime Video on Firefox ESR

Categories

(Web Compatibility :: Interventions, defect, P1)

defect

Tracking

(firefox-esr60- wontfix)

RESOLVED WONTFIX
Tracking Status
firefox-esr60 - wontfix

People

(Reporter: drno, Unassigned)

Details

(Whiteboard: [sitepatch-needed])

Apparently users on Firefox ESR can't watch Amazon Prime videos. They get an error message that their browser is not supported.

But if we change the User-Agent string everything works as expected. So it looks like Amazon is only blocking on the UA string.

Dennis, can we scope a UA override to be ESR only?

Flags: needinfo?(dschubert)
Priority: -- → P1

can we scope a UA override to be ESR only?

We sure can! One thing to note is that ESR 60 is still on the Web Compat GoFaster 1.1 - that's pre-WebExtension, so we would need to have a discussion on how to approach this.

I will file a bug in the WebCompat component, so we can have the discussion about the technical way to implement this there. Until then, I'll leave this ni? alive.

Edit: Uhm, I'm sorry. For some reason, I thought this was a TE bug, but it's already in the right component. Will follow-up with technical details.

Whiteboard: [sitepatch-needed]

Given that ESR60 isn't compatible with our WebExtension... I wonder if we could ship a pref update via Balrog, using general.useragent.site_specific_overrides, etc. Hmm

mythmon, looking at https://wiki.mozilla.org/Firefox/Normandy/PreferenceRollout, it mentions 61+. Just to be extra sure, this means we can't do a pref rollout to ESR 60?

Flags: needinfo?(mcooper)

Just for the record, I confirmed that creating a new pref general.useragent.override.amazon.de with Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 makes Amazon.de's Prime streaming working for me in ESR on Windows and Mac. Unfortunately, I can't test on Amazon.com because Amazon won't accept my account there, but this might be a try if we can get the pref rolled out.

Flags: needinfo?(dschubert)

Mike: You are right that we can't use preference rollout for ESR 60. We might however be able to use a different Normandy feature: preference "experiments" as a hotfix. We have used this feature to do hotfixes for Firefox releases, and it has worked well. The main difference between the two tools are that preference experiments are less sticky: users are more likely to fall out of them and get the value set back to default when compared to rollouts.

I think that a Normandy hotfix would be appropriate tool to patch this quickly, while we work on a more permanent solution.

Flags: needinfo?(mcooper)

Thank mythmon. Nils, do you want to run with the plan in Comment #6? I need to head out of town for a family emergency tonight, back on Monday.

(oops, please see Comment #7)

Flags: needinfo?(drno)

Yes the plan in comment #6 sounds fine to me. If it doesn't fix the problem for 100% of our ESR users I think that is acceptable.

Flags: needinfo?(drno)

Sorry for the delay here, this fell off my radar.

Dennis, do you know if it's possible to create a wildcard TLD ua spoof via prefs? Or would we have to set prefs for amazon.de, amazon.se, amazon.co.uk, etc?

Flags: needinfo?(dschubert)

We can't create a wildcard TLD spoof. *.amazon.* would be invalid, as stars only work at the beginning of a hostname, see here. Just like with eBay, we'd have to list all relevant domains.

Flags: needinfo?(dschubert)

Looking back at the reply, I think I should clarify: The link was targeted more towards our GoFaster approach. Technically, the prefs do use a different matching mechanism, but that doesn't support wildcards, either.

Nils, can you provide us with a list of TLDs where you want this to override to take effect?

Flags: needinfo?(drno)

Bryce can you please provide Mike with a list of domains we should unblock to get Amazon Video working?

Flags: needinfo?(drno) → needinfo?(bvandyk)

Our primary URLs have the format:
https://www.amazon.com/Prime-Video/<otherstuff>

I believe there are other URLs used outside the US, but I don't have a good way to iterate or test other URLs, so I'll just deal with the above.

If I've understood the page linked in comment 11, we could match on the following pattern for a conservative approach:
https://www.amazon.com/Prime-Video/*

Or for a more broad match:
https://*.amazon.com/*

Do we need to do further matching in order to handle other resources the page may fetch? Is this something I could test in order to help see if the above would be sufficient, or if we'd need other rules?

Flags: needinfo?(bvandyk) → needinfo?(dschubert)

Ah sorry for confusing everyone. As I attempted to clarify in comment 12, but failed. :) We actually can't use precise URL matches here, because ESR is, unfortunately, too old. We only can override per domain, and the override always includes all subdomains, so it'll always be a *://*.amazon.com/* type match.

So we only need a list of all the localized Amazon TLDs to build the names of the prefernce keys. Assuming their country selector is complete, that would be:

  • general.useragent.override.amazon.ca
  • general.useragent.override.amazon.cn
  • general.useragent.override.amazon.co.jp
  • general.useragent.override.amazon.co.uk
  • general.useragent.override.amazon.com
  • general.useragent.override.amazon.com.au
  • general.useragent.override.amazon.com.br
  • general.useragent.override.amazon.com.mx
  • general.useragent.override.amazon.com.tr
  • general.useragent.override.amazon.de
  • general.useragent.override.amazon.es
  • general.useragent.override.amazon.fr
  • general.useragent.override.amazon.in
  • general.useragent.override.amazon.it
  • general.useragent.override.amazon.nl

All set to a value of Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0.

Mike, is that enough information to proceed?

Flags: needinfo?(dschubert) → needinfo?(miket)

I believe so, but I want to verify with Nils that we want to override all TLDs, or restrict to a subset.

Flags: needinfo?(miket) → needinfo?(drno)

In the meantime, mythmon, what is the best way to roll out a preference experiment? Is there an expected format? Intent to ship on release drivers? I'm guessing we don't need an XPI for that kind of thing.

Flags: needinfo?(mcooper)

The entry point for preference experiments nowadays is with the Data Science team. The instructions for how to get started are here: https://mana.mozilla.org/wiki/display/PM/Firefox+Data+Science#FirefoxDataScience-initiatingaproject, in the "Initiating a project with the Data Science team" section (the Auth0 ridirection will likely remove the link hash, so you'll need to scroll down to the right section). From here you'll be guided through the expected steps.

You're right that no XPI should be needed.

Flags: needinfo?(mcooper)

Apologies, I didn't read enough context before sending my last comment. Since the goal here isn't actually an experiment, but a hot fix, we can use a much abbreviated process. Instead of filing a data science bug, please just send an intent to ship email that includes the reason for the change, what preference(s) you're changing, what population you are targeting (ie, 100% of ESR 60), and what schedule you'd like to use.

Additionally, please request that someone from release management explicitly approve the plan here in this bug.

Thanks Mythmon. Once we have confirmation on the locales, I'll send out an intent email and ask for an approval here.

(In reply to Mike Taylor [:miketaylr] from comment #17)

I believe so, but I want to verify with Nils that we want to override all TLDs, or restrict to a subset.

I think we want to "fix" this for as many pages as we can. My counter question would be:

  • How hard would be to roll-back in case we get reports about it causing problems?
  • Or if we don't initially include all countries how hard would be to extend it to more domains later?
Flags: needinfo?(drno)

My understanding is that roll-back is just another pref change (or I guess a pref deletion). I propose we start with the US, and if we don't receive complains push it out to others a week or so after.

Mythmon, can you just confirm the roll-back scenario I described?

Flags: needinfo?(mcooper)

Normandy hotfixes are fail-off, meaning that when we stop sending it to clients, they revert back to the previous configuration. That means that reverting this change is as simple as disabling it on the server. This is just as quick as the hotfix rollout.

Flags: needinfo?(mcooper)

[Tracking Requested - why for this release]:

As I mentioned in bug 1527747 comment 2, Amazon seems to require that the version number in the user agent is at least 62. Can someone from Mozilla maybe ask Amazon why they seem to require Firefox 62 or newer for no apparent reason? They don't mention this on their support page [1].

[1] https://www.amazon.com/gp/help/customer/display.html?nodeId=201422810

stpeter, were we able to get any updates from Amazon on this?

Flags: needinfo?(stpeter)

Hey miketaylr, I'm checking with folks at Amazon and I'll let you know what we hear!

Flags: needinfo?(stpeter)

I've been told that ESR was unblocked earlier this week!

(In reply to Peter Saint-Andre [:stpeter] from comment #29)

I've been told that ESR was unblocked earlier this week!

🥳 Nils, can you verify?

Flags: needinfo?(drno)

Looks good to me when I tested just now. Did we end up putting any mitigations in place? If not, seems like it's fixed on Amazon's end.

Flags: needinfo?(drno)

Awesome, thanks. We didn't end up shipping the interventions, hoping stpeter could work some magic -- and he delivered. :)

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
Summary: Amazon Prime Video blocked on Firefox ESR → Ship intervention to fix Amazon Prime Video on Firefox ESR

Eh, I dunno, maybe WONTFIX is better. Shrugs.

Resolution: INVALID → WONTFIX
You need to log in before you can comment on or make changes to this bug.