Limit MediaStream override of user gesture requirement to getUserMedia-originating MediaStreams
Reported by
phil...@opera.com,
Feb 29 2016
|
|||||||||
Issue descriptionhttps://chromium.googlesource.com/chromium/src/+/13afe0362f2e09a1bce83cef531a8b25d83b8ffe/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp#962 Here m_userGestureRequiredForPlay is cleared whenever a HTMLMediaElement is given a MediaStream. This made sense when all MediaStreams came from getUserMedia(), but doesn't make sense with captureStream() on HTMLMediaElement and HTMLCanvasElement, as it would provide a way to circumvent the user gesture requirement.
,
Feb 29 2016
I see... but I'm not really sure what we should do about it. Having mediastream video not playing automatically would be a pain for video calling (manually start both local and remote video). Even if we had a way of knowing that a MediaStream originated from a canvas, you could still circumvent it by looping the stream over a local peerconnection. Philip, how do you suggest the current behaviour should be changed?
,
Mar 1 2016
I imagined that the only current way of getting a MediaStream was with getUserMedia, but that obviously cannot be because there's also a remote side represented by a MediaStream. What's the API for getting that, and what does "looping the stream over a local peerconnection" look like?
I also see that there's already a way to disable the user gesture requirement using Web Audio:
<!DOCTYPE html>
<video controls></video>
<script>
var ac = new AudioContext;
var ms = ac.createMediaStreamDestination().stream;
var video = document.querySelector('video');
video.src = URL.createObjectURL(ms);
</script>
After this, any src can be set and played without a user gesture. This is an "improvement" compared to the workaround in https://foolip.org/2014/02/10/media-playback-restrictions-in-blink/demo.html
So, I'm not so sure if this should block captureStream() since it doesn't open up a new hole, it's just another one to add to the list.
I thought that the fix could be something like keeping track of which MediaStreamTracks originate from getUserMedia, but that doesn't sound any good if you join a videoconf without turning on your own camera.
,
Mar 1 2016
With looping over a peerconnection I mean something like this: https://webrtc.github.io/samples/src/content/peerconnection/pc1/.
,
Mar 1 2016
,
Mar 2 2016
Thanks Niklas! This demo uses the camera and microphone, but I guess the idea is that one could take a MediaStream from captureStream(), send it through an RTCPeerConnection, have it come out of another, and there would be no way to distinguish that from a videoconf call where you're merely watching/listening. liberato@, I don't have any good ideas for how to plug these holes. How's the autoplay experiment coming along? :)
,
Mar 8 2016
What's the user gesture requirement, where is it formally specified, and what is it intended to protect against? MediaStreams can be generated from MediaElements, WebAudio interfaces, PeerConnections or getUserMedia(). I suspect that there will be more sources in the future.
,
Mar 9 2016
The user gesture requirement is the check at the beginning of HTMLMediaElement::play() that can cause play() to bail out without playing. For many years this wasn't covered by any spec at all, but it is now explicitly allowed by https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-play This has its origin in WebKit ages ago: https://bugs.webkit.org/show_bug.cgi?id=23870 https://bugs.webkit.org/show_bug.cgi?id=24063 In what remains today there isn't a coherent design, but just ripping it out has met with resistance. For the time being, perhaps it would suffice to always allow playback of MediaStreams, but without clearing the m_userGestureRequiredForPlay for future resources.
,
Mar 18 2016
,
Mar 21 2016
Renaming Blink>Video to Blink>Media>Video for better characterization
,
May 10 2016
Merge Blink>CaptureStream into Blink>MediaCaptureFromElement
,
May 24 2016
Renamed Blink>MediaCaptureFromElement to Blink>MediaStream>CaptureFromElement. Moving issues to the new component.
,
Aug 9 2016
,
Sep 29 2016
,
Nov 15 2016
I believe comment #9 is now addressed. Please reopen if I am mistaken. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by jansson@chromium.org
, Feb 29 2016