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

> On Tue, Jul 9, 2013 at 7:16 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> 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.

> On 10/07/2013 5:02 AM, Rich Tibbett wrote:
> 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).
>

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.

Best regards,

Rich

[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html

[2] http://www.w3.org/TR/XMLHttpRequest1/#security-err

[3] http://www.w3.org/TR/domcore/#dom-domexception-security_err

Received on Wednesday, 10 July 2013 20:24:08 UTC