should the getDisplayMedia callback be treated as a user gesture? |
||||
Issue descriptionChrome Version: 71.0.3578.20 or higher OS: (e.g. Win10, MacOS 10.12, etc...) What steps will reproduce the problem? (1) go to https://webrtc.github.io/samples/src/content/peerconnection/pc1/ (2) click "start" (3) open the JS console, paste this into the JS console (requires experimental web platform features flags for getDisplayMedia and chrome://flags/#enable-surfaces-for-videos for pip/mediastreams): navigator.getDisplayMedia({video: true}).then(stream => { remoteVideo.srcObject = stream; localVideo.requestPictureInPicture() .catch(e => console.error(e.name, e)); }); What is the expected result? the local video element is popped out. What happens instead? A NotAllowedError is thrown. This suggests it is not called as the result of a user actvation, see https://wicg.github.io/picture-in-picture/#request-pip step 6. Unlike chooseDesktopMedia (which requires extensive extension/main context communication) it should be safe to treat the getDisplayMedia callback as having been triggered by user activation https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation Please use labels and text to provide additional information. If this is a regression (i.e., worked before), please consider using the bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help us identify the root cause and more rapidly triage the issue. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Oct 25
+mustaq I believe that makes sense. The getDisplayMedia callback (in success) is in response to a browser dialog that the user interacted with correct? There are no other scenarios in which the callback is called right? Like I'm thinking if you have already granted access once perhaps it calls Success without prompting the user. In those situations it would be incorrect to push a user activation then.
,
Oct 26
,
Oct 26
getUserMedia will grant you permission without interaction if you call it a second time, but getDisplayMedia will pop up the dialog asking what you want to share every time (and the spec is rather strident that you MUST ask the user what to share every time). So yes, I believe it makes sense to treat it as user activation.
,
Oct 26
While I see the usefulness in triggering a user activation in this case, I have concerns from activation abusability perspective. In this case, user interacts with the browser process, not with a specific renderer, which I think makes the bar higher for us. Here are my arguments: - Clicking "OK" on an alert() dialog doesn't immediately allow the caller page to spawn a popup today (I just confirmed it) because user didn't interact with the page. This looks like a deliberate behavior. Why should an user interaction with a getDisplayMedia dialog be different? - With multiple tabs open together, can a user easily associate getDisplayMedia dialog to a specific tab? Just mentioning the website on the dialog is not enough. - Coping with untrusted renderers is in our radar already (e.g. Issue 848778). It would be bad if any interaction with the browser ever enables an untrusted renderer do something that is otherwise blocked. dcheng@: any thoughts?
,
Oct 26
If the picker dialog isn't shown in a way that can easily be associated with the window that asked for it, we have a serious security issue anyway. @niklase can you comment on how this association is shown to the user? |
||||
►
Sign in to add a comment |
||||
Comment 1 by hta@chromium.org
, Oct 25