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

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

From: Rob Manson <roBman@mob-labs.com>
Date: Fri, 26 Jul 2013 09:43:47 +1000
Message-ID: <51F1B833.6020301@mob-labs.com>
To: public-webrtc@w3.org
+1 to that (as long as DEVICE_NOT_AVAILABLE includes both system errors 
and truly "not available" so it doesn't provide a fingerprinting issue).

Also, thanks for pointing out where the PERMISSION_DENIED came from 
Silvia 8) I was looking in the wrong spec (must have been tired).

So in this case the bug should be filed with Chrome and not Firefox. 
 From my tests the latest version of Chrome doesn't return 

As for your question:

   "JS can react and read what constraints the device supports
    (do we have such an API??)"


Returns a dictionary with all of the capabilities for the track type.

   6. Source capabilities
   Each constraint that is supported by an implementation MUST have an
   associated capability that will be returned in the result of a call
   to the capabilities() method. ...

   dictionary AllVideoCapabilities {
       CapabilityList?  sourceType;
       CapabilityList?  sourceId;
       CapabilityRange? width;
       CapabilityRange? height;
       CapabilityRange? frameRate;
       CapabilityList?  facingMode;


Returns an object containing all the state variables associated with the 
allowed constraints.

   5. Source states
   ... In the same way that the current set of constraints can be
   returned on a track using the constraints() method, the states()
   method on a track returns the values of the state variables
   associated with all capabilities, as the MediaSourceStates object. ...

   dictionary MediaSourceStates {
       SourceTypeEnum       sourceType;
       DOMString            sourceId;
       unsigned long?       width;
       unsigned long?       height;
       float?               frameRate;
       VideoFacingModeEnum? facingMode;
       unsigned long?       volume;

I need to do some more testing to clearly understand how these relate to 
each other, especially in the error conditions as in this case the 
MediaStream and therefore it's MediaStreamTrack's are not available so I 
assume these will simply not be able to be used. However, Firefox and 
Chrome haven't implemented these MST methods yet.


On 26/07/13 08:17, 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?
>>      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.
> 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?
>      -> 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?
>      -> 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
> Cheers,
> Silvia.
Received on Thursday, 25 July 2013 23:44:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC