W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 Jul 2013 08:18:55 -0700
Message-ID: <CABcZeBO_HkTaOvHGKDEwzM+U4EjCew3NH6HEBmUCbyBBobHavA@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Jul 25, 2013 at 6:02 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> Alex and Martin,
>     I'd like to bring your attention to https://code.google.com/p/**
> chromium/issues/detail?id=**257104<https://code.google.com/p/chromium/issues/detail?id=257104>.
> This issue was filed before initiating a discussion on the list.
>     It was the browser vendor who (rightfully so) suggested that the
> WebRTC specification needs to be changed in order for them to make the
> necessary changes in Chrome.

Uh, it wasn't "the browser vendor", it was one person who works on Chromium
and as I read his message, he doesn't say that they want to make the changes
but merely that:

"Expanding the NavigatorUserMediaErrorName enums probably merits discussion
W3C or WebRTC lists and is therefore not suitable for tracking in a single

Which seems rather more noncommittal.

    What now?

Uh, you've raised it, and we're discussing it now. I don't see that you're
that much support, but as a matter of process I suppose you could ask the
chairs for meeting time to discuss it followed by a consensus call.


> Gili
> On 25/07/2013 3:39 AM, Alexey Aylarov wrote:
>> 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 15:20:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC