[webkit-dev] Improving DOM Exception console messages.
Brendan Eich
brendan at mozilla.org
Mon Oct 1 17:43:12 PDT 2012
Ojan Vafai 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.
That error messages and details differ among browsers is not the issue.
The cross-browser concern is the security model that distinguishes
errors that can be presented fully to JS and the inspector or a console,
and those than must be censored from JS.
/be
>
>
>
> On Mon, Oct 1, 2012 at 4:56 PM, Ojan Vafai <ojan at google.com
> <mailto: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
> <mailto: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
> <mailto: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
> <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 <mailto: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
> <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
> <mailto:webkit-dev at lists.webkit.org>
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
More information about the webkit-dev
mailing list