- 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. Paul.
Received on Friday, 12 July 2013 10:02:29 UTC