[webkit-dev] Improving DOM Exception console messages.

Mon Oct 1 02:57:55 PDT 2012

I had a brief conversation about this with Adam and Maciej on IRC
about this, and Ojan chimed in on the bug[1]. 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
information to JavaScript by making the exception's message more
detailed. For example, if if a resource allowed by CSP redirects to a
resource disallowed by CSP, we shouldn't give JavaScript access to the
latter URL.

2. Adam suggested storing the context on the exception object, using
it for rendering in the console but not exposing it to JavaScript. The
current patch does this for JSC[2].

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 ([3] for instance); for
that error, I don't think there's any concern with providing the same
string to JavaScript and to the Inspector. For security errors
involving redirects and other information that JavaScript shouldn't
have access to, we could go the more complicated route of providing
one string to JavaScript, and the other to the Inspector.

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
strings.

Does that seem like a tenable solution?

-Mike

[1]: https://bugs.webkit.org/show_bug.cgi?id=97654
[2]: https://bugs.webkit.org/attachment.cgi?id=166300&action=prettypatch
[3]: 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 = 'https://api.twitter.com/1/trends/daily.json?exclude=hashtags';
>       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[1]. 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[2], 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?
>
> [1]: https://cs.corp.google.com/#search/&q=SECURITY_ERR%20file:WebCore&sq=package:%5Echrome$&type=cs
> [2]: http://stackoverflow.com/questions/2704929/uncaught-error-security-err-dom-exception-18
>
> -Mike