RESOLVED FIXED Bug 221187
Permission request API for MediaKeySystem access support
https://bugs.webkit.org/show_bug.cgi?id=221187
Summary Permission request API for MediaKeySystem access support
Philippe Normand
Reported 2021-01-31 09:12:54 PST
At least GTK/WPE would like to have API for asking permission to the user when EME's MediaKeyAccess is being requested by a page. On Apple platforms the permission is granted by default until a decision is made about supporting this in their APIUIClient.
Attachments
Patch (138.77 KB, patch)
2021-01-31 09:30 PST, Philippe Normand
no flags
Patch (158.45 KB, patch)
2021-02-01 04:03 PST, Philippe Normand
ews-feeder: commit-queue-
Patch (157.92 KB, patch)
2021-02-01 04:06 PST, Philippe Normand
ews-feeder: commit-queue-
Patch (158.11 KB, patch)
2021-02-01 04:18 PST, Philippe Normand
ews-feeder: commit-queue-
Patch (157.92 KB, patch)
2021-02-01 04:41 PST, Philippe Normand
no flags
Patch (125.31 KB, patch)
2021-02-01 05:04 PST, Philippe Normand
ews-feeder: commit-queue-
Patch (135.49 KB, patch)
2021-02-01 08:19 PST, Philippe Normand
no flags
Patch (135.51 KB, patch)
2021-02-02 03:05 PST, Philippe Normand
no flags
Patch (136.51 KB, patch)
2021-02-02 03:08 PST, Philippe Normand
no flags
Patch (134.24 KB, patch)
2021-02-05 02:58 PST, Philippe Normand
ews-feeder: commit-queue-
Patch (134.69 KB, patch)
2021-02-05 03:12 PST, Philippe Normand
jer.noble: review+
Philippe Normand
Comment 1 2021-01-31 09:30:05 PST
EWS Watchlist
Comment 2 2021-01-31 09:31:30 PST
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Philippe Normand
Comment 3 2021-01-31 09:32:34 PST
I expect apple's EWS to fail. I'll check the build issues.
Philippe Normand
Comment 4 2021-02-01 04:03:18 PST
Philippe Normand
Comment 5 2021-02-01 04:06:14 PST
Philippe Normand
Comment 6 2021-02-01 04:18:10 PST
Philippe Normand
Comment 7 2021-02-01 04:41:42 PST
Philippe Normand
Comment 8 2021-02-01 05:04:42 PST
Philippe Normand
Comment 9 2021-02-01 06:47:55 PST
mac-wk1 layout tests failing, most likely because of missing UIDelegate support for the permission request. I'll check it. Any hints regarding the watch/tv build failures would be welcome though!
Philippe Normand
Comment 10 2021-02-01 08:19:17 PST
Philippe Normand
Comment 11 2021-02-02 03:05:23 PST
Philippe Normand
Comment 12 2021-02-02 03:08:33 PST
Jer Noble
Comment 13 2021-02-04 17:55:04 PST
Comment on attachment 418980 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=418980&action=review > Source/WebCore/Modules/encryptedmedia/MediaKeySystemClient.h:29 > +#include <wtf/CompletionHandler.h> This doesn't look necessary; could this be removed? > Source/WebCore/Modules/encryptedmedia/MediaKeySystemClient.h:48 > +WEBCORE_EXPORT void provideMediaKeySystemTo(Page*, MediaKeySystemClient*); Both these should probably be references. > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:29 > +#include "FeaturePolicy.h" Could this be moved into the implementation file? > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:31 > +#include "Page.h" Ditto here, but the `from()` method would need to be un-inlined, which is fine since supplementName() is already in the implementation file also. > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:32 > +#include <wtf/CompletionHandler.h> This doesn't appear to be used. > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:41 > + explicit MediaKeySystemController(MediaKeySystemClient*); This should take a reference; and MediaKeySystemClient should probably be a CanMakeWeakPtr. > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:44 > + MediaKeySystemClient* client() const { return m_client; } Is this really needed? > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:55 > + MediaKeySystemClient* m_client; This should probably be a WeakPtr<MediaKeySystemClient>. > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:60 > + m_client->requestMediaKeySystem(request); This should have a NULL check. > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.h:65 > + m_client->cancelMediaKeySystemRequest(request); Ditto. > Source/WebKit/UIProcess/MediaKeySystemPermissionRequest.h:29 > +#include <WebCore/ClientOrigin.h> This doesn't seem to be used. Can it be moved to the implementation file? > Source/WebKit/UIProcess/MediaKeySystemPermissionRequestManagerProxy.h:31 > +#include <wtf/CompletionHandler.h> > +#include <wtf/Deque.h> These doesn't appear to be used. > Source/WebKit/UIProcess/MediaKeySystemPermissionRequestManagerProxy.h:35 > +#include <wtf/RunLoop.h> > +#include <wtf/Seconds.h> Ditto. > Source/WebKit/UIProcess/MediaKeySystemPermissionRequestManagerProxy.h:50 > +#if !RELEASE_LOG_DISABLED > + , private LoggerHelper > +#endif So, ... > Source/WebKit/UIProcess/MediaKeySystemPermissionRequestManagerProxy.h:72 > +#if !RELEASE_LOG_DISABLED > + const Logger& logger() const final; > + const void* logIdentifier() const final { return m_logIdentifier; } > + const char* logClassName() const override { return "MediaKeySystemPermissionRequestManagerProxy"; } > + WTFLogChannel& logChannel() const final; > +#endif It turns out there's not a great reason to explicitly inherit from LoggerHelper (unless a subclass relies upon them); these methods just need to be defined in the scope in which LOG macro appears. The methods need to exist, but it's also fine just to define them as local statics, if needed. Also, this means you don't need the LoggerHelper.h header (nor even Logger or WTFLogChannel, if they're forward declared). > Source/WebKit/UIProcess/MediaKeySystemPermissionRequestManagerProxy.h:80 > + Ref<const Logger> m_logger; This isn't needed, as you just get the Logger from the page. > Source/WebKit/UIProcess/MediaKeySystemPermissionRequestProxy.h:68 > + MediaKeySystemPermissionRequestManagerProxy* m_manager; This should be a `WeakPtr<MediaKeySystemPermissionRequestManagerProxy>`. > Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.cpp:37 > +#include <WebCore/CARingBuffer.h> > +#include <WebCore/WebAudioBufferList.h> Is this perhaps an unrelated change? > Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.h:30 > +#include "SharedMemory.h" Ditto? > Source/WebKit/UIProcess/WebPageProxy.cpp:10465 > + completionHandler(false); This appears to deny all media key system access unless clients specifically add a UIClient to do the reverse, which is a breaking change. Could this just be "true" by default instead? > Source/WebKitLegacy/mac/WebCoreSupport/WebMediaKeySystemClient.h:34 > + WebView *webView() { return m_webView; } This never appears to be called. Is it necessary, or indeed is the WebView* needed at all? > Source/WebKitLegacy/mac/WebCoreSupport/WebMediaKeySystemClient.mm:43 > +void WebMediaKeySystemClient::pageDestroyed() > +{ > + delete this; > +} This seems really weird. (Same above, too.)
Jer Noble
Comment 14 2021-02-04 17:57:47 PST
(In reply to Philippe Normand from comment #9) > mac-wk1 layout tests failing, most likely because of missing UIDelegate > support for the permission request. I'll check it. > > Any hints regarding the watch/tv build failures would be welcome though! Looks like MediaKeySystemRequest is guarded by `#if ENABLE(MEDIA_STREAM)` not `#if ENABLE(ENCRYPTED_MEDIA)`. And the former isn't enabled on TV or watchOS.
Philippe Normand
Comment 15 2021-02-05 02:58:06 PST
Philippe Normand
Comment 16 2021-02-05 02:58:27 PST
Comment on attachment 418980 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=418980&action=review Thanks Jer! >> Source/WebKit/UIProcess/MediaKeySystemPermissionRequest.h:29 >> +#include <WebCore/ClientOrigin.h> > > This doesn't seem to be used. Can it be moved to the implementation file? The class is entirely implemented in the header. >> Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.cpp:37 >> +#include <WebCore/WebAudioBufferList.h> > > Is this perhaps an unrelated change? Actually it is relevant to this patch, which somehow changes the unified build "layout" :/
Philippe Normand
Comment 17 2021-02-05 03:00:38 PST
(In reply to Jer Noble from comment #14) > (In reply to Philippe Normand from comment #9) > > mac-wk1 layout tests failing, most likely because of missing UIDelegate > > support for the permission request. I'll check it. > > > > Any hints regarding the watch/tv build failures would be welcome though! > > Looks like MediaKeySystemRequest is guarded by `#if ENABLE(MEDIA_STREAM)` > not `#if ENABLE(ENCRYPTED_MEDIA)`. And the former isn't enabled on TV or > watchOS. Oh wow, nice catch! 😅
Philippe Normand
Comment 18 2021-02-05 03:12:50 PST
Jer Noble
Comment 19 2021-02-06 15:58:30 PST
Comment on attachment 419384 [details] Patch r=me, with one comment: View in context: https://bugs.webkit.org/attachment.cgi?id=419384&action=review > Source/WebCore/Modules/encryptedmedia/MediaKeySystemController.cpp:57 > + m_client->pageDestroyed(); Null check?
Radar WebKit Bug Importer
Comment 20 2021-02-07 09:13:13 PST
Philippe Normand
Comment 21 2021-02-08 00:38:25 PST
Ryan Haddad
Comment 22 2021-02-08 10:59:12 PST
Follow-up fix for macCatalyst in https://trac.webkit.org/changeset/272500/webkit
Philippe Normand
Comment 23 2021-02-08 11:05:32 PST
Thanks Ryan, sorry for the trouble.
WebKit Commit Bot
Comment 24 2021-02-08 16:37:32 PST
Re-opened since this is blocked by bug 221586
Philippe Normand
Comment 25 2021-02-09 04:16:30 PST
Fix: diff --git a/Source/WebCore/Modules/encryptedmedia/MediaKeySystemRequest.cpp b/Source/WebCore/Modules/encryptedmedia/MediaKeySystemRequest.cpp index e669715e5de7..2a2fec324b0d 100644 --- a/Source/WebCore/Modules/encryptedmedia/MediaKeySystemRequest.cpp +++ b/Source/WebCore/Modules/encryptedmedia/MediaKeySystemRequest.cpp @@ -48,6 +48,7 @@ Ref<MediaKeySystemRequest> MediaKeySystemRequest::create(Document& document, con MediaKeySystemRequest::MediaKeySystemRequest(Document& document, const String& keySystem, Ref<DeferredPromise>&& promise) : ActiveDOMObject(document) + , m_identifier(MediaKeySystemRequestIdentifier::generate()) , m_keySystem(keySystem) , m_promise(WTFMove(promise)) {
Philippe Normand
Comment 26 2021-02-09 04:46:53 PST
Peng Liu
Comment 27 2021-04-09 11:41:27 PDT
This patch breaks Netflix playback on macOS Big Sur. See bug 224384.
Peng Liu
Comment 28 2021-04-09 18:53:57 PDT
(In reply to Peng Liu from comment #27) > This patch breaks Netflix playback on macOS Big Sur. See bug 224384.
Philippe Normand
Comment 29 2021-04-10 01:40:37 PDT
Comment on attachment 419384 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419384&action=review > Source/WebKit/UIProcess/API/C/WKPage.cpp:2129 > + if (!m_client.decidePolicyForMediaKeySystemPermissionRequest) { > + completionHandler(false); > + return; > + } Can you check if this hit by Safari? I suspect this is the bug, if your APIUIClient doesn´t have a decidePolicyForMediaKeySystemPermissionRequest handler, the permission request is denied.
Eric Carlson
Comment 30 2021-04-11 10:49:03 PDT
Comment on attachment 419384 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419384&action=review >> Source/WebKit/UIProcess/API/C/WKPage.cpp:2129 >> + } > > Can you check if this hit by Safari? I suspect this is the bug, if your APIUIClient doesn´t have a decidePolicyForMediaKeySystemPermissionRequest handler, the permission request is denied. Your initial comment in this bug was "On Apple platforms the permission is granted by default until a decision is made about supporting this in their APIUIClient". Did this change?
Philippe Normand
Comment 31 2021-04-11 11:37:04 PDT
(In reply to Eric Carlson from comment #30) > Comment on attachment 419384 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=419384&action=review > > >> Source/WebKit/UIProcess/API/C/WKPage.cpp:2129 > >> + } > > > > Can you check if this hit by Safari? I suspect this is the bug, if your APIUIClient doesn´t have a decidePolicyForMediaKeySystemPermissionRequest handler, the permission request is denied. > > Your initial comment in this bug was "On Apple platforms the permission is > granted by default until a decision is made about supporting this in their > APIUIClient". Did this change? No. I was just commenting on this specific part of the patch because of a hunch. I don't have a Netflix account, so can't reproduce this issue. Are you sure this is a WebKit issue? Can you provide a reduced test-case?
Peng Liu
Comment 32 2021-04-12 10:26:35 PDT
(In reply to Philippe Normand from comment #29) > Comment on attachment 419384 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=419384&action=review > > > Source/WebKit/UIProcess/API/C/WKPage.cpp:2129 > > + if (!m_client.decidePolicyForMediaKeySystemPermissionRequest) { > > + completionHandler(false); > > + return; > > + } > > Can you check if this hit by Safari? I suspect this is the bug, if your > APIUIClient doesn´t have a decidePolicyForMediaKeySystemPermissionRequest > handler, the permission request is denied. I just tested. When the issue happens, function `WebPageProxy::requestMediaKeySystemPermissionForFrame()` is not called at all. The reason seems to be that the WebContent process is in the background and the IPC message is not delivered to the UI process.
Peng Liu
Comment 33 2021-04-12 11:21:13 PDT
Comment on attachment 419384 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419384&action=review > Source/WebKit/WebProcess/EncryptedMedia/MediaKeySystemPermissionRequestManager.cpp:61 > + sendMediaKeySystemRequest(request); A bug here. When we open a tab in the background, the request won't be sent, and we won't retry when the tab goes to foreground.
Philippe Normand
Comment 34 2021-04-12 11:45:47 PDT
Comment on attachment 419384 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419384&action=review >> Source/WebKit/WebProcess/EncryptedMedia/MediaKeySystemPermissionRequestManager.cpp:61 >> + sendMediaKeySystemRequest(request); > > A bug here. When we open a tab in the background, the request won't be sent, and we won't retry when the tab goes to foreground. Ah! Would the MediaCanStartListener be triggered in such case?
Peng Liu
Comment 35 2021-04-12 11:49:29 PDT
Comment on attachment 419384 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=419384&action=review >>> Source/WebKit/WebProcess/EncryptedMedia/MediaKeySystemPermissionRequestManager.cpp:61 >>> + sendMediaKeySystemRequest(request); >> >> A bug here. When we open a tab in the background, the request won't be sent, and we won't retry when the tab goes to foreground. > > Ah! Would the MediaCanStartListener be triggered in such case? Yes. Just had a discussion with Eric and Jer. Will upload a patch for review after test. :-)
Philippe Normand
Comment 36 2021-04-12 11:50:59 PDT
Thanks Peng!
Peng Liu
Comment 37 2021-04-12 15:37:56 PDT
(In reply to Philippe Normand from comment #36) > Thanks Peng! My pleasure. :-) Let's close this bug. The issue we discussed will be fixed in bug 224384.
Note You need to log in before you can comment on or make changes to this bug.