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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
