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

On 2013-07-12 10:19, Adam Bergkvist wrote:
> 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.

I managed to get it wrong the second time as well. :) The error name I 
was meaning to refer to is INCOMPATIBLE_CONSTRAINTS (will be 
IncompatibleConstraintsError in the next release).

/Adam

>> 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 09:02:03 UTC