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

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

Received on Thursday, 11 July 2013 12:30:15 UTC