Affected versions

• Firefox Developer Edition 69.0b1 (20190701201355)

Affected platforms

• Windows 10 x64 (aarch64)

Steps to reproduce

1. Launch Firefox and log in with valid credentials on https://www.netflix.com.
2. Play a random video.

Expected result

• The video starts playing.

Actual result

• An error is thrown in Browser Console and the user is redirected to https://help.netflix.com/en/node/23742.

Regression Range

• Firefox Developer Edition 68.0b3 (20190520131124) and 67.0b3 (20190318154932) are also affected. I will search for a regression range ASAP.

Additional Notes

• Firefox 68.0b14 (20190627143605), Firefox 68.0 (20190701181138) and Firefox 69.0a1 (20190702093917) are not afected.
• Widevine plugin is not installed and no DRM Content can be found on about:preferences page.
• After trying to play a video the following errors are presented multiple times in the browser console:
  MediaKeySystemAccess::GetKeySystemStatus(com.widevine.alpha) result=cdm-not-supported msg=''
  navigator.requestMediaKeySystemAccess promise rejected 0x80530009 ''
  MediaKeySystemAccess::GetKeySystemStatus(com.widevine.alpha) result=cdm-not-supported msg=''
  navigator.requestMediaKeySystemAccess promise rejected 0x80530009 ''.

Bryce, what's the status for widevine on arm64?

Am investigating. We support widevine in general here, so there's something about the dev edition which is causing the bustage.

With a fresh profile in dev edition I don't even see the checkbox to enable DRM content in the options (hamburger menu -> Options -> General -> Just under the applications heading is where the box is normally located). This is because browser.eme.ui is set to false.

Aside from that we don't have either of

media.gmp-widevinecdm.enabled
media.gmp-widevinecdm.visible

set, which means widevine is disabled via these means.

However, even if I toggle all these on Widevine still doesn't work, so there's something more going on here. Continuing to investigate.

Sounds like some config for the deved was not changed when we did the other platforms for aarch64. Waiting to hear back on https://bugzilla.mozilla.org/show_bug.cgi?id=1527463#c25

Copying reply from that bug as it informs our short term fix here:

(In reply to Tom Prince [:tomprince] from comment #27)

(In reply to Bryce Seager van Dyk (:bryce) from comment #25)

Would having the dev ed derive from shippables be something we could do in the short term?

I'm not familiar enough with branding or the build process to do this work, or even scope it out. It looks (at a quick glance) like
the differences are:

• branding
• MOZ_REQUIRE_SIGNING
• MOZ_ALLOW_LEGACY_EXTENSIONS
  Grepping suggests that the later two configs are only looked at in js code (they end up in AppConstants.jsm, so in theory we could generate devedition builds by repacking the non-deved builds). However, all this is novel work, so I don't think it is a good short term solution.

Probably the best short-term solution is to duplicate the work of this bug for devedition.

NI myself to take a look at what is involved in that when I have a moment.

Maybe it's time to have another look at this? Maybe enough other things have changed and we can just close this.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Hello! Tried searching for a regression range but with no luck, because Firefox 67.0b2 DevEdition (20190314152045) is also affected which is the first build for arm. So I think it's safe to assume that this is not a regression.

Also, the issue is still reproducible on Firefox 73.0b1 DevEdition (20200106175743). Updating the flags.

I don't think there's a lot of interest in fixing the build for aarch. I believe fixing the build would resolve this, but I'm not sure who's domain that is, and don't foresee having cycles in the near future to delve this. I'll look at creating a bug in the build system to block this one.