[webkit-dev] Improving DOM Exception console messages.

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[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/6a6594fa/attachment.html>