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

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 from file:// 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.

Thanks,
Gili