- 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