Re: Improve error message when browser denies access to getUserMedia()

I agree with Rob, UX is still far from being perfect, but I'm not sure trying to add some UX requirements into the standard is the right approach. I usually try to contact browser vendors and tell them how it could be improved. It worked with Google really well, but Mozilla is slower with that , maybe because they were a little behind Google in development.

For example, in Mozilla GetUserMedia dialog can disappear when window lost focus, if we consider many users don't have any experience with WebRTC yet, it's hard for them to find out that they need to click on the icon in the address bar to show the dialog again. But you, as app developer, can add some UI element on the page to help them - not perfect solution, but better than nothing.

-Alexey

On Jul 25, 2013, at 9:06, Rob Manson <roBman@mob-labs.com> wrote:

> Hi Martin,
> 
> well that's not the way that Firefox handles it. It returns PERMISSION_DENIED (which is basically what I was asking for - thanks Mozilla 8) ). And it doesn't cache your response by default (except if you allow and it's using https I believe).
> 
> So the two main WebRTC browsers are already behaving differently here 8/
> 
> Surely the spec IS the place to define consistent behaviour for browser?
> 
> This is not a major technical issue and it's not a very complex thing to work out so I'm not sure why this is "a very long lever"?  Isn't this sort of consistency the thing we should be looking for?  Otherwise it makes us web developers have to jump through lots of UA sniffing hoops!
> 
> And my original response was primarily to Cullen's comment that this was a fingerprinting risk...and I still stand by my comments about that.
> 
> roBman
> 
> On 25/07/13 13:17, Martin Thomson wrote:
>> On 24 July 2013 17:33, Rob Manson <roBman@mob-labs.com> wrote:
>>> There is a real benefit to return a different error response based on
>>> whether the user denied access or the system failed to gain access.
>> 
>> It turns out that the two are equivalent, 100%.  Whether you knew it
>> or not, telling Chrome[1] to reject a request for microphone access is
>> something that is persistent.  You are asking Chrome to reject all
>> future attempts to access that microphone.  So, when a site asks again
>> later, it is YOU, not your browser that rejects the request.
>> 
>> I can't believe the length of this thread.  If you don't like the
>> behavior of your browser, either change browsers, or ask the
>> developers nicely to fix it.  If, as I suspect is the case here, it's
>> your users that inadvertently disadvantage themselves, the latter
>> option might be the best approach, but changing the spec is a very
>> long lever, and the wrong one in this case.
>> 
>> [1] I don't want to pick on Chrome specifically here, but I know that
>> is how they operate.
>

Received on Thursday, 25 July 2013 07:58:44 UTC