RESOLVED FIXED 216872
Introduce WKWebViewConfiguration mediaCaptureEnabled
https://bugs.webkit.org/show_bug.cgi?id=216872
Summary Introduce WKWebViewConfiguration mediaCaptureEnabled
youenn fablet
Reported 2020-09-23 05:02:21 PDT
Introduce WKWebViewConfiguration mediaDevicesEnabled
Attachments
Patch (20.62 KB, patch)
2020-09-23 05:05 PDT, youenn fablet
no flags
Patch (21.40 KB, patch)
2020-09-23 05:32 PDT, youenn fablet
no flags
Patch (23.43 KB, patch)
2020-09-23 08:25 PDT, youenn fablet
no flags
Patch for landing (22.19 KB, patch)
2020-09-25 02:45 PDT, youenn fablet
no flags
Patch for landing (22.23 KB, patch)
2020-09-25 04:12 PDT, youenn fablet
no flags
youenn fablet
Comment 1 2020-09-23 05:05:33 PDT
youenn fablet
Comment 2 2020-09-23 05:32:05 PDT
Sam Weinig
Comment 3 2020-09-23 07:39:00 PDT
Comment on attachment 409465 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=409465&action=review > Source/WebKit/ChangeLog:11 > + Add a new boolean configuration to enable/disable mediaDevices exposure. > + Value is off by default. > + A future patch will remove the WebPreferences based API, given there is no need > + to enable/disable mediaDevices throughout the course of a page. Can you explain a bit more about why you are moving this? Most feature enablement is currently done through the preferences mechanism, so having this one be on the configuration seems odd and inconsistent. If there is new thought process around this, it would be good to have that articulated so we can start the process of migrating everything.
youenn fablet
Comment 4 2020-09-23 07:52:03 PDT
(In reply to Sam Weinig from comment #3) > Comment on attachment 409465 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=409465&action=review > > > Source/WebKit/ChangeLog:11 > > + Add a new boolean configuration to enable/disable mediaDevices exposure. > > + Value is off by default. > > + A future patch will remove the WebPreferences based API, given there is no need > > + to enable/disable mediaDevices throughout the course of a page. > > Can you explain a bit more about why you are moving this? Most feature > enablement is currently done through the preferences mechanism, so having > this one be on the configuration seems odd and inconsistent. I am not sure how much this is inconsistent. There is not much API available in WKPreferences.h. There are some precedents in WKWebViewConfiguration.h, like allowsAirPlayForMediaPlayback. > If there is new thought process around this, it would be good to have that > articulated so we can start the process of migrating everything. WebPreferences can be changed during the lifetime of the page. This can be useful, say you want to enable/disable mock devices. In that particular case, I see no use case for enabling/disabling this setting during the lifetime of the page. There are some downsides of allowing it (some contexts may have navigator.mediaDevices, some may not). It seems best to enforce a fixed setting hence the idea to move it to WKWebViewConfiguration. Wdyt?
Alex Christensen
Comment 5 2020-09-23 08:11:36 PDT
Comment on attachment 409465 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=409465&action=review > Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfiguration.mm:172 > + BOOL _mediaDevicesEnabled; This should go on API::PageConfiguration instead. > Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:123 > +@property (nonatomic, setter=_setMediaDevicesEnabled:) BOOL _mediaDevicesEnabled WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); Could you deprecate the preference SPI with this as a replacement?
youenn fablet
Comment 6 2020-09-23 08:20:45 PDT
(In reply to Alex Christensen from comment #5) > Comment on attachment 409465 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=409465&action=review > > > Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfiguration.mm:172 > > + BOOL _mediaDevicesEnabled; > > This should go on API::PageConfiguration instead. OK. > > Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:123 > > +@property (nonatomic, setter=_setMediaDevicesEnabled:) BOOL _mediaDevicesEnabled WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA)); > > Could you deprecate the preference SPI with this as a replacement? Sure, I plan to remove the preference SPI as a follow-up though.
youenn fablet
Comment 7 2020-09-23 08:25:59 PDT
Radar WebKit Bug Importer
Comment 8 2020-09-23 09:41:54 PDT
Sam Weinig
Comment 9 2020-09-23 09:44:54 PDT
(In reply to youenn fablet from comment #4) > (In reply to Sam Weinig from comment #3) > > Comment on attachment 409465 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=409465&action=review > > > > > Source/WebKit/ChangeLog:11 > > > + Add a new boolean configuration to enable/disable mediaDevices exposure. > > > + Value is off by default. > > > + A future patch will remove the WebPreferences based API, given there is no need > > > + to enable/disable mediaDevices throughout the course of a page. > > > > Can you explain a bit more about why you are moving this? Most feature > > enablement is currently done through the preferences mechanism, so having > > this one be on the configuration seems odd and inconsistent. > > I am not sure how much this is inconsistent. > There is not much API available in WKPreferences.h. > There are some precedents in WKWebViewConfiguration.h, like > allowsAirPlayForMediaPlayback. The preferences expose all the preferences set in the WebPreferences*.yaml files. There are a ton of them. They don't each necessarily get their own corresponding WKPreferences API call site, but most can accessed via the enumerations for internal debug or experimental features accessors. > > > If there is new thought process around this, it would be good to have that > > articulated so we can start the process of migrating everything. > > WebPreferences can be changed during the lifetime of the page. > This can be useful, say you want to enable/disable mock devices. > > In that particular case, I see no use case for enabling/disabling this > setting during the lifetime of the page. There are some downsides of > allowing it (some contexts may have navigator.mediaDevices, some may not). > It seems best to enforce a fixed setting hence the idea to move it to > WKWebViewConfiguration. > Wdyt? It's hard to judge as I don't know what your intended use case for this is. Who is the target audience of this SPI?
Radar WebKit Bug Importer
Comment 10 2020-09-23 09:45:31 PDT
youenn fablet
Comment 11 2020-09-23 10:10:11 PDT
> > In that particular case, I see no use case for enabling/disabling this > > setting during the lifetime of the page. There are some downsides of > > allowing it (some contexts may have navigator.mediaDevices, some may not). > > It seems best to enforce a fixed setting hence the idea to move it to > > WKWebViewConfiguration. > > Wdyt? > > It's hard to judge as I don't know what your intended use case for this is. > Who is the target audience of this SPI? Goal is not to stay at SPI.
Alex Christensen
Comment 12 2020-09-23 13:05:47 PDT
Comment on attachment 409475 [details] Patch Actually, we may want to put this on WKWebpagePreferences.
Alex Christensen
Comment 13 2020-09-23 13:41:00 PDT
Comment on attachment 409475 [details] Patch The WKUIDelegate needs to give permission, and that can be per-site. This is great.
youenn fablet
Comment 14 2020-09-24 11:31:19 PDT
We might want to rename mediaDevicesEnabled to mediaCaptureEnabled which intent is clearer.
youenn fablet
Comment 15 2020-09-25 02:45:12 PDT
Created attachment 409676 [details] Patch for landing
youenn fablet
Comment 16 2020-09-25 04:12:16 PDT
Created attachment 409678 [details] Patch for landing
EWS
Comment 17 2020-09-25 04:49:02 PDT
Committed r267563: <https://trac.webkit.org/changeset/267563> All reviewed patches have been landed. Closing bug and clearing flags on attachment 409678 [details].
youenn fablet
Comment 18 2020-09-25 04:59:34 PDT
Note You need to log in before you can comment on or make changes to this bug.