Issue metadata
Sign in to add a comment
|
requestMediaKeySystemAccess promise never fulfilled on ChromeOS |
||||||||||||||||||||||||||
Issue descriptionChrome Version: 60.0.3105.0 OS: ChromeOS What steps will reproduce the problem? (1) Navigate to any https site, e.g. https://permission.site (2) Open the dev console (3) Run the JS script in [1] below. (4) Observe that the promise of requestMediaKeySystemAccess call is resolved, and we see the console log. (5) Refresh the tab. (6) Repeat (3). [1] Script to run: var widevineOptions = [ { initDataTypes: [ 'cenc' ], persistentState: "required", videoCapabilities: [ { contentType: 'video/mp4;codecs="avc1.4d401e"' } ] } ]; navigator.requestMediaKeySystemAccess('com.widevine.alpha', widevineOptions) .then(function(keySystemAccess) { config = keySystemAccess.getConfiguration(); }); console.log(config.persistentState); What is the expected result? The requestMediaKeySystemAccess promise is still resolved. What happens instead? The requestMediaKeySystemAccess promise is pending forever and never fulfilled. Please use labels and text to provide additional information. 1. This can also be reproduced on a debug ChromeOS Chrome build on Linux. It cannot be reproduced on a Linux Chrome build on Linux. We couldn't repro on Mac Canary either. 2. This does not reproduce on 60.0.3084.0 3. This is actually affecting real world protected content playback. See issue 725587.
,
May 24 2017
Jason did some manual bisecting tests. Here are some updates: Good: 60.0.3096.0 Bad: 60.0.3100.0 There are two builds (3098 and 3099) between bad and good. Jason is on that.
,
May 24 2017
60.0.3100.0 with CDM 977 fail with Amazon 60.0.3098.0 with CDM 977 fail with Amazon *worked one time 60.0.3096.0 with CDM 977 works with Amazon *retested and still works
,
May 24 2017
+reillyg who made changes to PermissionServiceImpl recently. +dcheng for questions about what we should do about connected mojo services during navigation. The issue is caused by https://codereview.chromium.org/2842013002. Before the change, when navigating to a new document, permission service will NOT be disconnected, and can still be used by the RenderFrameImpl. After the change, when navigating to a new document, we'll disconnect the permission service. Currently MediaPermissionDispatcher (the client in the render process) doesn't handle connection error, because it assumes that the service will not be disconnected unless the RenderFrameHost is destroyed, which apparently isn't true now. I can fix this by handling the connection error in MediaPermissionDispatcher. But before I do that, I have a few questions: reillyg / dcheng: What's the rationale behind disconnecting the service on navigation? It seems to me that it's a simpler model to always have the permission service alive as long as the RenderFrameImpl is alive. Basically, only reject requests during navigation. But I guess we could hit a race between RenderFrameHostChanged and the connection error. dcheng: I still don't understand why this only repros on ChromeOS build. Do we have different policy about whether we reuse the same RenderFrameImpl when refreshing the tab?
,
May 24 2017
I already have a patch which reconnects the MediaPermissionDispatcher on navigation: https://chromium-review.googlesource.com/c/513387/ The reason that we disconnect the service on navigation is that permission prompts are tied to an origin and unless we can assert that RenderFrameHost::GetLastCommittedOrigin() does not change for the lifetime of a RenderFrameHost we should be disconnecting services that care about origin on navigation.
,
May 24 2017
reillyg: Great! Thanks for the fix. I'll retest when that CL lands. dcheng: Ignore my question on why this only happens on ChromeOS. We actually only request permission for EME on ChromeOS and Android. That's why we don't see this issue on Linux/Win/Mac.
,
May 25 2017
@xhwang My question is... why do we only see it on Link, and do not see it on the 2 ARM-based Chromebooks we have tested on?
,
Jun 8 2017
This should have been fixed on 60.0.3112.24 and above. embry: Could you please help verify the fix?
,
Jun 9 2017
I looked at this on Chrome 60.0.3112.26, ChrOS (LINK) build 9592.15.0, CDM 1.4.8.1000. No problems at all playing AIV content. LGTM.
,
Jun 9 2017
Just to double check. Did you run the repro steps in #1 (since this isn't super reliable repro on AIV) ?
,
Jun 9 2017
Ah, ok. Yes, verified using the steps outlines in original bug. LGTM.
,
Jun 13 2017
think there's a typo above. The CDM is "version": "1.4.8.1005" for 9592.15.0 Also played Guardians on AIV with link and 60.0.3112.26 with 9592.15.0 I also see no issues. |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by xhw...@chromium.org
, May 24 2017