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