- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 11 Jul 2013 17:06:57 +0200
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Cc: cowwoc <cowwoc@bbs.darktech.org>, public-media-capture@w3.org
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). br/ Rich
Received on Thursday, 11 July 2013 15:07:28 UTC