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

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.

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

Thank you,
Paul.



On Thursday, 11 July 2013 at 13:28, cowwoc wrote:

> On 11/07/2013 5:34 AM, Adam Bergkvist wrote:
> > > I posted the following message before your reply. I'm re-quoting it
> > > here to make sure we don't miss any details:
> > > 
> > > > I find it highly unlikely that we will be able to eliminate all
> > > > cases where access is denied by a non-user actor. Consider the
> > > > following example:
> > > > 
> > > > 1. Chrome queries the hardware for a list of available cameras,
> > > > populates the list and asks the user for permission.
> > > > 2. Some process grabs exclusive control of the camera, or the user
> > > > pulls out the camera, or the camera is defective, etc.
> > > > 3. User clicks "grant access".
> > > > 4. WebRTC returns PERMISSION_DENIED but the user never denied access.
> > > > 
> > > > From a UI perspective, we need to differentiate between as many of
> > > > the following cases as possible:
> > > > 
> > > > 1. User denying access.
> > > > 2. Browser denying access.
> > > > 3. OS denying access (other process has exclusive lock).
> > > > 4. Hardware error.
> > > > 5. Camera removed.
> > > > 6. Application error.
> > > > 
> > > > I used to think that having a single enum with a different String
> > > > messages would be sufficient, but I no longer think that this is the
> > > > case. We don't want to force applications to parse a String to figure
> > > > out what went wrong. A String error reason (if added) should be purely
> > > > for human consumption.
> > > > 
> > > 
> > > 
> > > So you're saying case #1 and #6 should be covered by existing
> > > WebRTC error callbacks, and cases #2, 3, 4, 5 would result in an
> > > exception being thrown.
> > > 
> > > I have the following concerns with that approach:
> > > 
> > > * The specification should spell out what exceptions to expect for
> > > cases 2-5 (currently it does not)
> > > * A month ago there was a discussion of making the API more consistent
> > > by returning all errors (whether PERMISSION_DENIED or an exception)
> > > through the error callback. What happened to this discussion? It
> > > would affect us in this case.
> > > 
> > 
> > 
> > I agree with Martins reasoning that the browser acts as an agent for 
> > the user. So it shouldn't be different if the user actively rejects 
> > (1) or has instructed the browser to reject any subsequent requests 
> > (2) from this site. Then it's a UI thing to inform the user if only 
> > this request is blocked or subsequent requests as well.
> > 
> > I'm on Gili's line when it comes to reporting these errors. I don't 
> > see why we should throw exceptions in certain cases and use the error 
> > callback in others for this category of errors. We should use 
> > exceptions to detect programming errors and malformed requests.
> > 
> > What is Application error (6) is this context?
> > 
> > /Adam
> Hi Adam,
> 
> On the one hand you're saying that we should get back the same enum 
> for access denied by user or browser, but at the same time you're saying 
> we should be able to display a different UI depending on either 
> situation. Isn't that a contradiction? If your application is a video 
> conferencing tool and some users call customer support saying "It 
> doesn't work" then you're going to find it difficult to diagnose why. 
> And in most cases users won't bother calling customer support. They'll 
> just drop your application.
> 
> Regarding using exceptions, it has the added advantage of 
> encouraging browsers to supply a detailed string message explaining why 
> the error occurs, which I believe is important for developers.
> 
> Application error (6) was meant to refer to all other application 
> errors not currently covered by the spec, such as passing invalid or 
> contradictory constraints into getUserMedia(). I believe this should be 
> a different error than CONSTRAINT_NOT_SATISFIED because the latter 
> depends on runtime conditions (it might fail one moment, then work when 
> you plug in a new camera) whereas the latter is a fatal programming error.
> 
> Gili