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

On 10/07/2013 5:02 AM, Rich Tibbett wrote:
> On Tue, Jul 9, 2013 at 7:16 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> Hi,
>>
>> This is a follow-up discussion to
>> https://code.google.com/p/chromium/issues/detail?id=257104
>>
>> The WebRTC specification needs to provide a better error message in case the
>> browser denies access to the camera, instead of the user. Currently, the
>> specification states that PERMISSION_DENIED is the result of the user
>> denying access. Instead of simply modifying the definition of
>> PERMISSION_DENIED to cover both cases, I propose splitting it into separate
>> cases:
>>
>> PERMISSION_DENIED_BY_USER
>> PERMISSION_DENIED_BY_BROWSER
>>
>> Alternatively, we need to add a String error message alongside the enum, and
>> require browsers to issue a different error message for each case.
> Why? What do you plan to do in your web page if you had this
> additional information today?
>
> If this information can be used to improve the user experience then it
> would be good to know what the use cases are. My hunch is that, if
> anything, this change opens the door to allowing web sites to
> developing a negative attitude toward users who deny camera access and
> for those pages to potentially continually bug users who have
> explicitly rejected camera permissions until they accept (or give in
> and leave the web page frustrated). That would not be a good outcome
> here. Whether the permission is denied by the user, the platform, by
> some content policy or by some future permissions management system
> should largely be irrelevant for web pages.
>
> Also, it would be better to discuss this on
> public-media-capture@w3.org (I've CCed that list and any follow-up
> posts should remove public-webrtc@w3.org from replies).
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:

 1. The application failed to run because the user denied camera access
    (and explain how to re-enable it)
 2. The application may not run under this context, regardless of user
    action (and why)
 3. An application bug was detected (and how to report it)

Gili