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 <[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]> 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]> 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
