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

On 2013-07-11 17:06, 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.

Thanks for clarifying. I agree that when it comes to standard DOM-level 
security violations, it's a different case that has nothing to do with 
the consistent way WebRTC should report errors.

/Adam

Received on Friday, 12 July 2013 08:25:57 UTC