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

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
in
W3C or WebRTC lists and is therefore not suitable for tracking in a single
bug."

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
getting
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.


-Ekr


> 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.
>>>>
>>>
>
>