W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2013

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Fri, 12 Jul 2013 10:25:34 +0200
Message-ID: <51DFBD7E.6080904@ericsson.com>
To: Rich Tibbett <richt@opera.com>
CC: cowwoc <cowwoc@bbs.darktech.org>, <public-media-capture@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC