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

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

From: Paul Neave <paul.neave@gmail.com>
Date: Fri, 12 Jul 2013 11:01:58 +0100
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: cowwoc <cowwoc@bbs.darktech.org>, Rich Tibbett <richt@opera.com>, public-media-capture@w3.org
Message-ID: <ED153A0B90554B699DA7B05710FC577D@gmail.com>

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.

Received on Friday, 12 July 2013 10:02:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC