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

On 2013-07-11 14: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.

When I read my own text I see that I was a bit unclear about the UI 
thing. What a meant was that I think browsers need to be clear about 
what happens when a user denies a page access; is it only this time or 
until you go into some settings page and clear a flag. So I was talking 
about browser UI.

>      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.

The NavigatorUserMediaError object we provide as argument to the error 
callback has a message property. So it doesn't have to be that different 
in this case.

>      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.

We have INVALID_SESSION_DESCRIPTION and INCOMPATIBLE_SESSION_DESCRIPTION 
error names in the WebRTC spec. Perhaps these should be moved here; they 
would still be usable by the WebRTC spec since it depends on this one.

/Adam

Received on Thursday, 11 July 2013 13:09:13 UTC