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

On Thu, Jul 25, 2013 at 12:39 AM, Alexey Aylarov <alexey@zingaya.com> 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.


Hi Alexey,

I think this is an intentional feature, but I tend to agree that it's not
great.

That said, I don't see a bug for this from you. Can you either send me
the bug number or file one and then send me the bug number?

-Ekr


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