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

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Fri, 12 Jul 2013 10:19:04 +0200
Message-ID: <51DFBBF8.1090200@ericsson.com>
To: Paul Neave <paul.neave@gmail.com>
CC: cowwoc <cowwoc@bbs.darktech.org>, Rich Tibbett <richt@opera.com>, <public-media-capture@w3.org>
On 2013-07-11 15:33, Paul Neave wrote:
> I am a developer and I use the getUserMedia API extensively, and a big
> frustration for me is the poor error responses returned in the
> getUserMedia error callback. Chrome currently only responds with
> PERMISSION_DENIED, although CONSTRAINT_NOT_SATISFIED is being
> implemented (see http://crbug.com/246184).
>
> There was talk of adding two more error codes in a previous discussion.
> See
> http://lists.w3.org/Archives/Public/public-media-capture/2012May/0042.html
> and http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0151.html
>
> Firefox have implemented a non-standard NO_DEVICES_FOUND error for the
> case when no device for audio/video is available. I think this is a good
> approach as I think a separate error would be better than conflating
> with the CONSTRAINT_NOT_SATISFIED error, which should only be for cases
> when a specific mandatory constraint cannot be met.
>
> Firefox also uses a non-standard HARDWARE_UNAVAILABLE error for when a
> device exists but for some reason cannot be used (such as, it is already
> in use by another webpage or program).
>
> So to follow on from these implementations, I'd like to suggest the
> following to be formally added to the spec:
>
> 1. PERMISSION_DENIED - User explicitly denied device access via the
> browser UI
> 2. CONSTRAINT_NOT_SATISFIED - Device access is not possible given
> overambitious *mandatory* constraints
> 3. HARDWARE_UNAVAILABLE - There is a suitable device connected but a
> hardware error occurred (such as OS/program/webpage lock)
> 4. NO_DEVICES_FOUND - There are no suitable devices connected whatsoever
>
> 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.

As I wrote in an earlier mail, we could consider adding 
INVALID_SESSION_DESCRIPTION and INCOMPATIBLE_SESSION_DESCRIPTION to the 
list as well since these are already defined in the WebRTC spec and they 
apply equally well here.

> There was also talk of having NavigatorUserMediaError inherit from
> DOMError, so all of these error code should really be in camelCase, not
> UPPER_CASE, see here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22216

This is fixed [1] and will be in the next editor's draft.

/Adam

[1] 
https://github.com/fluffy/webrtc-w3c/commit/7ca3ba9fc2df0401a269528d57554c895d4dcd4a
Received on Friday, 12 July 2013 08:19:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC