1288976 - [EME] navigator.requestMediaKeySystemAccess promises don't resolve promptly or give up waiting when CDM not yet downloaded

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Testcase

STR:
1. Ensure e10s enabled.
2. Disable "Play DRM Content" in about:preferences.
3. Open attached testcase.
4. Click "Enable DRM" notification box that drops down from browser chrome.
5. Wait for CDMs to download and install.

Expected result: After Widevine and Primetime CDMs download, the navigator.requestMediaKeySystemAccess() promises will resolve successfully, and "Got Adobe MediaKeySystemAccess" and "Got Widevine MediaKeySystemAccess" will be logged.

Observed result:
1. with e10s disabled:
Exception creating Widevine CDM: Gave up while waiting for a CDM update
Got Adobe MediaKeySystemAccess

2. With e10s enabled:
After 60 seconds, promises resolve successfully. It should happen as soon as the CDMs download, not after we hit the timeout.

What's happening in the non-e10s case, is when the Adobe CDM downloads, we're retrying *all* requests under the assumption that we only get the "retry" notification when the CDM we're requesting has downloaded. This assumption was fine when we only had one CDM, but we don't anymore. So the since we have the Adobe CDM but not the Widevine CDM (since we download them serially), we reject the Widevine request promise.

In the e10s case, we don't forward the "gmp-path-added" notification across from the chrome process to the content process. So we timeout after 60 seconds, retry the requests, and they succeed.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1288976 - Use gmp-changed rather than gmp-path-added to retry MediaKeys requests.

We're already routing the "gmp-changed" observer service notification over from
the chrome process to the content process, and it fires at pretty much the same
time as the "gmp-path-added" notification (and a few more) so we can just switch
to have the MediaKeySystemAccessManager listen on that notification instead, and
we'll be e10s compatible.

Review commit: https://reviewboard.mozilla.org/r/66750/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/66750/

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Bug 1288976 - Only retry MediaKeySystemAccess requests on 'gmp-changed' notification if the CDM is now installed.

This ensures we'll only retry requests if we know the install operation has
completed for a given GMP. This means if (say) OpenH264 happens to install
while we have a Widevine request pending, we won't retry the Widevine request,
as that would fail. The Widevine request will retry once the Widevine CDM
has downloaded and in turn fires its gmp-changed notification.

Review commit: https://reviewboard.mozilla.org/r/66752/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/66752/

Comment 3

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Comment on attachment 8774210 [details]
Bug 1288976 - Use gmp-changed rather than gmp-path-added to retry MediaKeys requests.

https://reviewboard.mozilla.org/r/66750/#review63482

Comment 4

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Comment on attachment 8774211 [details]
Bug 1288976 - Only retry MediaKeySystemAccess requests on 'gmp-changed' notification if the CDM is now installed.

https://reviewboard.mozilla.org/r/66752/#review63488

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9f4d0adc2e73
Use gmp-changed rather than gmp-path-added to retry MediaKeys requests. r=gerald
https://hg.mozilla.org/integration/autoland/rev/05b9ca6b58ec
Only retry MediaKeySystemAccess requests on 'gmp-changed' notification if the CDM is now installed. r=gerald

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9f4d0adc2e73
https://hg.mozilla.org/mozilla-central/rev/05b9ca6b58ec

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8774210 [details]
Bug 1288976 - Use gmp-changed rather than gmp-path-added to retry MediaKeys requests.

Requesting uplift for Firefox 49.

Approval Request Comment
[Feature/regressing bug #]: EME/e10s.
[User impact if declined]: In multi-process Firefox, if the user tries to use a site which uses EME, and the CDM plugin isn't downloaded and installed yet, the site may hang forever. In single-process Firefox, there may be up to a 60 second delay.

This patch also fixes a problem where if another GMP (such as OpenH264, Adobe Primetime, or Widevine) installs while a request to start EME is pending because the CDM isn't finished downloading, EME will fail to start. I believe this is causing an small but noticeable number (< 1%) of failures on Amazon Prime Video and Netflix.

[Describe test coverage new/current, TreeHerder]: We've got lots of EME mochitests, but none covering the "install and then resume" feature here, as it requires downloading the CDM, which we can't do from our test harness.
[Risks and why]: Low
[String/UUID change made/needed]: None.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8774211 [details]
Bug 1288976 - Only retry MediaKeySystemAccess requests on 'gmp-changed' notification if the CDM is now installed.

Requesting uplift for Firefox 49.

Approval Request Comment
[Feature/regressing bug #]: EME/e10s.
[User impact if declined]: In multi-process Firefox, if the user tries to use a site which uses EME, and the CDM plugin isn't downloaded and installed yet, the site may hang forever. In single-process Firefox, there may be up to a 60 second delay.

This patch also fixes a problem where if another GMP (such as OpenH264, Adobe Primetime, or Widevine) installs while a request to start EME is pending because the CDM isn't finished downloading, EME will fail to start. I believe this is causing an small but noticeable number (< 1%) of failures on Amazon Prime Video and Netflix.

[Describe test coverage new/current, TreeHerder]: We've got lots of EME mochitests, but none covering the "install and then resume" feature here, as it requires downloading the CDM, which we can't do from our test harness.
[Risks and why]: Low
[String/UUID change made/needed]: None.

Comment 9

[Gerry Chang [:gchang]]

Comment on attachment 8774210 [details]
Bug 1288976 - Use gmp-changed rather than gmp-path-added to retry MediaKeys requests.

This will affect Netflix users and the patch fixes the hang issue. Take it in aurora.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4950c39e834e
https://hg.mozilla.org/releases/mozilla-aurora/rev/04a6cd9d45f9