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

On 2013-07-10 22:33, cowwoc wrote:
> Hi Rich,
>
>      Replies below.
>
> On 10/07/2013 4:23 PM, Rich Tibbett wrote:
>> On Wed, Jul 10, 2013 at 6:31 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>> Hi Rich,
>>>
>>>      I'll repeat what I wrote to Adam on public-webrtc.
>>>
>>>      Having two separate error messages makes it easier to diagnose the
>>> problem. I spent 2 hours trying to figure out why the browser was denying
>>> access to the camera without prompting me (the user). It's actually a lot
>>> harder to differentiate between user, browser or application errors than
>>> you'd think. In the case of Chrome, it was denying access to the camera
>>> immediately but then showed a camera icon in the top right corner that, when
>>> clicked, asked "Continue blocking camera access for this website? Ask next
>>> time this website tries accessing the camera?". Meaning, Chrome was
>>> misrepresenting what was going on ... as if the user had a choice to grant
>>> access or that they were ever prompted to do so (neither of which was the
>>> case).
>>>
>>>      A production-ready WebRTC application with a polished UI needs to
>>> differentiate and report at least three separate errors:
>>>
>>> - The application failed to run because the user denied camera access (and
>>> explain how to re-enable it)
>>> - The application may not run under this context, regardless of user action
>>> (and why)
>>> - An application bug was detected (and how to report it)
>> So, the current media capture specification [1] does not define any
>> exceptions around getUserMedia and I'm unsure if that is by design or
>> has just not yet been discussed on this list yet.
>>
>> Throwing exceptions back to developers would probably be the right
>> abstraction to use here rather than tying this problem in to the error
>> codes provided via the error callbacks.
>>
>> We may only need exceptions initially to cover calls to getUserMedia
>> from File URI-based pages. In this case, the media capture
>> specification could dictate that implementations throw a SECURITY_ERR
>> exception as currently defined in (and re-used from) XMLHttpRequest
>> [2] (FWIW, this is also defined directly in the DOM Core specification
>> itself @ [3]).
>>
>> Exceptions would seem to solve the issue you've highlighted in a
>> practical way for developers to debug their applications when
>> attempting to e.g. access getUserMedia fromfile://  while having
>> little impact on the overall permission_denied framework currently in
>> place which was created _by design_ rather than out of neglect for
>> other error types in an effort to maintain user privacy to some
>> degree. Web developers could observe errors on the console output in
>> their browser of choice like they already do today.
>>
>> Once we have exception handling defined in the media capture
>> specification there may be other things we might like to throw
>> for...but we can probably leave that for a separate discussion.
>
>      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

Received on Thursday, 11 July 2013 09:34:27 UTC