- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Fri, 9 Jan 2015 17:19:20 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi, Currently Chrome behaves in a very "hateful" way when it comes to calling getUserMedia from a callback (instead of being triggered by a user 'click' action). I know such a "issue" is reported but cannot find it right now. My question is: is that the way in which the API is defined? To be clear, the following "fails" in Chrome: -------------- setTimeout(function() { getUserMedia( {video:true}, function() {}, function(error) { console.error(error); } ) }, 2000); -------------- It "fails" since the "getUserMedia" prompt is not displayed until the user moves to another tab or application and comes back to this one. I consider this behavior hateful given that it breaks basic flows as the following: ------------- // Incoming SDP offer is received (var sdp) // First try to set it as remote description pc.setRemoteDescription( new RTCSessionDescription({type:'offer', sdp:sdp}), // If valid, prompt the user for audio/video. getUserMedia({video:true}, onSuccess, onFailure), // failure function(error) { console.error(error); } ); function onSuccess(stream) { // createAnswer, setLocalDescription, etc etc } ------------- This does "not" work because getUserMedia is called in a callback (of course, I want to be sure that the received SDP is valid before I prompt the user for gUM !). So my question again: is this how gUM is supposed to work? or a fanciful design in Chrome browser? -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Friday, 9 January 2015 16:20:07 UTC