- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 25 Jul 2013 19:54:00 -0400
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 25/07/2013 6:17 PM, Silvia Pfeiffer wrote: > On Fri, Jul 26, 2013 at 1:51 AM, cowwoc <cowwoc@bbs.darktech.org> wrote: >> I think there is a misunderstanding of the issue. I am asking to >> differentiate between: >> >> * Access denied by the user (whether directly or by way of a saved preference) > Looking at http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-NavigatorUserMediaError, > that's the error message PERMISSION_DENIED > >> * Access denied by the browser > and this would be CONSTRAINT_NOT_SATISFIED - or wouldn't it? I'll quickly recap what is going on: When I execute my application from http:// it works. When I execute the exact same application from file:// it fails on getUserMedia(). Why? Apparently Chrome denies local HTML files access to the microphone and camera. See https://code.google.com/p/chromium/issues/detail?id=257104 Anyway, what's important to mention is that I am passing in the exact same Constraints in both cases but only one scenario is failing. Hence, the function parameters are not at fault, the execution context is. >> The former is recoverable. The latter is fatal (likely a programming >> bug). >> >> I am *not* asking to differentiate between a user denying access >> directly versus denying access by way of a saved preference. > PERMISSION_DENIED_USER and PERMISSION_DENIED_BROWSER don't seem the > right choice of names then. > > Maybe you can specify more clearly what case you'd like flagged that > is different from CONSTRAINT_NOT_SATISFIED ? > > > Is it e.g. something like DEVICE_NOT_AVAILABLE ? Then I could imagine > the browser going: > > 1. Did the user (at some stage) disallow me to access the device? > Yes: flag PERMISSION_DENIED error > -> JS can react and bring up informative dialog > (I'd actually prefer that to the browser bringing up the dialog - > maybe there should be a way to ask the browser not to bring up the > dialog?) > No: proceed > > 2. Can I get to the device? > No: flag DEVICE_NOT_AVAILABLE error > -> JS can react and bring up a dialog telling the user to check > the camera connection > Yes: proceed > > 3. Can I get the stream from the device with the given constraints? > No: flag CONSTRAINT_NOT_SATISFIED error > -> JS can react and read what constraints the device supports (do > we have such an API??) or at least try a different constraint set > Yes: proceed Yes, this would satisfy me. It has the added bonus of returning DEVICE_NOT_AVAILABLE if initially the device was available but it was physically unplugged before the user selected Allow Access. Final point: I seem to remember the spec editors planning to add a String parameter alongside the enum to elaborate on the error. In that case, I would encourage the browser to return a different human-readable explanation for DEVICE_NOT_AVAILABLE depending on whether the device was physically unplugged versus when access was denied for security reasons. I would then show this message to the user of the application, to differentiate between the two. If you think this is a fingerprinting risk, then at least print the error to the Developer Console (which, as far as I know, can't be used for fingerprinting). Thanks, Gili
Received on Thursday, 25 July 2013 23:54:52 UTC