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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC