[webkit-dev] Improving DOM Exception console messages.

Mon Oct 1 10:52:16 PDT 2012

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[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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121001/972169f6/attachment.html>