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

On 10/07/2013 12:18 PM, Martin Thomson wrote:
> On 10 July 2013 08:11, Erin Spiceland <espiceland@digium.com> wrote:
>> The current behavior in Chrome is that if the user ever denies
>> media on the call to getUserMedia, the browser will permanently block
>> media and automatically deny subsequent requests, immediately calling
>> the failure callback, without asking the user. I am not certain if the
>> behavior is the same when using HTTPS. To unblock the site, the user
>> has to go into Chrome's media preferences
>> (chrome://settings/contentExceptions#media-stream) and remove the
>> domain from the blocked list.
> Perhaps this issue is then a consequence of a specific implementation
> choice.  I'd suggest that people who are unhappy with this behavior
> talk to those that implemented this and attempt to have it fixed
> there.
>
> The browser acts as an agent for the user, from the application
> perspective, receiving a rejection from either party must be
> considered equivalent.

     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.

Gili