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

On 11/07/2013 11:06 AM, Rich Tibbett wrote:
> On Thu, Jul 11, 2013 at 11:34 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com> wrote:
>> 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.
> The original Chromium bug that started this thread was talking about
> accessing getUserMedia from a file:// context and when proposing to
> throw exceptions I was only speaking to that part of the discussion.
>
> In such a case and, so far it seems, in only this case, throwing a
> SECURITY_ERR exception (or a NOT_SUPPORTED exception) would seem like
> the standard thing to do. This particular error (i.e access  being
> prohibited from any file:// origin) is triggered immediately as a
> result of a standard DOM-level security violation rather than from any
> underlying getUserMedia/WebRTC implementation errors or issues. As
> such I think it is separate enough to throw as an exception rather
> than as an error code in the async error callback function. The best
> analogy I can think of here is the subtle difference we maintain
> between Exceptions vs. HTTP Error codes in e.g. the XHR API. There is
> a reason we have both exceptions and error codes in that API and
> having that separation is useful.
>
> There's a second discussion going on here about changing the error
> codes provided in the error callback but DOM-based security or syntax
> errors are likely sufficiently different as to be treatable in the
> standard way (as exceptions).

     My own preference is for all errors to funneled through the error 
callback and get returned as exceptions. Once you have some exceptions 
being returned asynchronously, it's easier to handle all errors in the 
same problem.

Gili

Received on Friday, 12 July 2013 02:56:01 UTC