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

RESOLVED FIXED in Firefox 49

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: cpearce, Assigned: cpearce)

Tracking

(Blocks: 1 bug)

unspecified
mozilla50
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox49 fixed, firefox50 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments)

(Assignee)

Description

2 years ago
Created attachment 8774157 [details]
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.
(Assignee)

Comment 1

2 years ago
Created attachment 8774210 [details]
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/
Attachment #8774210 - Flags: review?(gsquelart)
Attachment #8774211 - Flags: review?(gsquelart)
(Assignee)

Comment 2

2 years ago
Created attachment 8774211 [details]
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/
Attachment #8774210 - Flags: review?(gsquelart) → review+
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 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
Attachment #8774211 - Flags: review?(gsquelart) → review+

Comment 5

2 years ago
Pushed by cpearce@mozilla.com:
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

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/9f4d0adc2e73
https://hg.mozilla.org/mozilla-central/rev/05b9ca6b58ec
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox50: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
(Assignee)

Comment 7

2 years ago
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.
Attachment #8774210 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 8

2 years ago
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.
Attachment #8774211 - Flags: approval-mozilla-aurora?

Updated

2 years ago
status-firefox49: --- → affected
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.
Attachment #8774210 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

2 years ago
Attachment #8774211 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.