On Friday, 12 July 2013 at 10:01, Adam Bergkvist wrote:
> > > These four cover most use cases in my opinion. One remaining point I
> > > agree with is that it would be useful to know whether the user pressed
> > > the "deny" button, or if the browser has device access disabled (by the
> > > user some time previously or otherwise). So perhaps a fifth error code
> > >
> > > 5. PERMISSION_NOT_ALLOWED - Browser denied device access
> > >
> > > or something else simple and similar to PERMISSION_DENIED would be good.
> >
> > I think the first four is a good start. Regarding #5, Rich asked a valid
> > question in a previous mail: what would you do with this extra
> > information? He had some concerns that are worth thinking about as well.
>
Regarding the question that kicked off this thread, this secondary "browser denied" error code would be useful, specifically in Chrome's case.
Chrome uses a "sticky deny" approach so that when a user clicks the deny button, any subsequent getUserMedia requests will immediately fail. If the user clicks X to simply dismiss the getUserMedia request, subsequent requests can still be made. In this scenario, a better error code response would allow developers to inform the user what actually happened and what to do to fix the problem (i.e. allow access requests by re-enabling in the browser, or by simply requesting access again).
Personally I think the sticky deny approach is bad user experience and I don't see what real value or security it adds, but that's a conversation for another list (see http://crbug.com/167263). No other browser implements a sticky deny.
Paul.