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

On 2013-07-11 15:08, Adam Bergkvist wrote:
> 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.

Correction (again): I was meaning to say INCOMPATIBLE_CONSTRAINTS.

/Adam

Received on Friday, 12 July 2013 09:04:37 UTC