[webkit-dev] Improving DOM Exception console messages.
ojan at chromium.org
Mon Oct 1 17:18:10 PDT 2012
This isn't spec'ed anywhere. I agree it would be ideal to get a spec for
this, but I don't think we need to block on that in this instance. This is
an area where browsers are completely incompatible already. I don't see
much benefit from blocking on creating a specification to make this
situation better for web developers. It's actually not that big of a deal
if the error messages from different browsers are different.
On Mon, Oct 1, 2012 at 4:56 PM, Ojan Vafai <ojan at google.com> wrote:
> This isn't spec'ed anywhere. I agree it would be ideal to get a spec for
> this, but I don't think we need to block on that in this instance. This is
> an area where browsers are completely incompatible already. I don't see
> much benefit from blocking on creating a specification to make this
> situation better for web developers. It's actually not that big of a deal
> if the error messages from different browsers are different.
> On Mon, Oct 1, 2012 at 10:52 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> Where is this spec'ed? If we're exposing this to the Web, we definitely a
>> spec. for this BEFORE implementing it in WebKit.
>> On Mon, Oct 1, 2012 at 2:57 AM, Mike West <mkwst at chromium.org> wrote:
>>> I had a brief conversation about this with Adam and Maciej on IRC
>>> about this, and Ojan chimed in on the bug. Since I'm in the wrong
>>> time-zone for discussion (and I'd like a wider audience anyway), I'm
>>> pulling this back to the list.
>>> 1. Maciej raised the concern that we might be exposing sensitive
>>> detailed. For example, if if a resource allowed by CSP redirects to a
>>> latter URL.
>>> 2. Adam suggested storing the context on the exception object, using
>>> current patch does this for JSC.
>>> 3. On the bug, Ojan noted that many apps on the web send stack traces
>>> back to the server for analysis, and exposing context only to the
>>> Inspector would deprive these apps of context.
>>> I'd like to ensure that we end up with a solution that WebKit
>>> developers will actually use.
>>> One solution would be to treat SECURITY_ERR differently than other DOM
>>> exceptions. For instance, SYNTAX_ERR is thrown in a variety of
>>> contexts where security seems to be unaffected ( for instance); for
>>> that error, I don't think there's any concern with providing the same
>>> have access to, we could go the more complicated route of providing
>>> Concretely, this might involve adding two properties to ExceptionBase:
>>> 'context' and 'totallySektitContext' (or similar... :) ). The first
>>> would always be appended to the message generated in ExceptionBase's
>>> constructor, the latter only when the error is reported to the
>>> console. At each setDOMException callsite, we'd have to provide some
>>> mechanism for setting one or both strings. This might involve turning
>>> ExceptionCode enum into a struct containing the code and slots for two
>>> Does that seem like a tenable solution?
>>> : https://bugs.webkit.org/show_bug.cgi?id=97654
>>> : https://bugs.webkit.org/attachment.cgi?id=166300&action=prettypatch
>>> : https://bugs.webkit.org/show_bug.cgi?id=97984
>>> On Wed, Sep 26, 2012 at 5:12 PM, Mike West <mkwst at chromium.org> wrote:
>>> > Hello, webkit-dev!
>>> > TL;DR: I'd like to improve the console messages displayed for DOM
>>> > exceptions. I'm hoping that no one thinks this is a miserable,
>>> > miserable idea.
>>> > At the moment, the following code generates an exception with a
>>> > message reading "SECURITY_ERR: DOM Exception 18".
>>> > ----8<------8<------8<------
>>> > <!doctype html>
>>> > <html>
>>> > <head>
>>> > <title>Bug 152212</title>
>>> > <meta http-equiv="X-WebKit-CSP" content="connect-src 'none'">
>>> > </head>
>>> > <body>
>>> > <script>
>>> > var xhr = new XMLHttpRequest();
>>> > var url = '
>>> > xhr.open('GET', url, true);
>>> > xhr.send();
>>> > </script>
>>> > </body>
>>> > </html>
>>> > ---->8------>8------>8------
>>> > In this case, the exception is generated because Content Security
>>> > Policy blocks the XMLHttpRequest, but it's tough to tell, because the
>>> > exact same error crops up for 31 different exception cases. It
>>> > might be CSP, it might be a disallowed HTTP method, who knows. Because
>>> > of the variety, searching for the exception message is unhelpful. In
>>> > this case, I end up on StackOverflow, reading about cookies and
>>> > jQuery, which is unlikely to be of service.
>>> > This isn't a great experience, and while SECURITY_ERR is particularly
>>> > widespread, the scenario is similar for the other DOM exceptions
>>> > WebKit throws. Each ends up in ExceptionBase, where a message is
>>> > assembled from the exception type and code, and the developer is left
>>> > more than a little underinformed.
>>> > I'd like to add the ability to pass some sort of contextual message
>>> > along with the error code. This would involve some work on JSC and V8
>>> > bindings, as well as a whole lot of single-line changes to the various
>>> > bits of the DOM where these error codes are generated.
>>> > In this case, a useful message might be: "SECURITY_ERR: DOM Exception
>>> > 18. XMLHttpRequest connections to
>>> > 'http://localhost:8000/xmlhttprequest/resources/get.txt' are blocked
>>> > due to this page's Content Security Policy." This would have the
>>> > positive impact of giving developers something useful to work with. It
>>> > would also have the impact of changing the exception text, which is
>>> > why I'm writing this email. :)
>>> > Before I get too far along in experimental implementations, are there
>>> > fundamental objections to changing the exception text to include some
>>> > optional context?
>>> > :
>>> > :
>>> > -Mike
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev