Mads and I spoke by chat. Our current plan is to align these error messages with JSC after V8's M6 code freeze. The main cost of doing that is that web developers will get dumbed down error messages. We're going to try to surface this information in the web inspector similarly to how we surface HTML parse errors (that is, in a little red bubble next to the actual parse error in the source).
Adam On Tue, Jul 13, 2010 at 8:43 AM, Mads Ager <[email protected]> wrote: > That one should be easy yes. I find it counter-productive to dumb down > that exception message though. Could you explain a security scenario > where this is a problem? > > If there is a strong argument that a decent parse error message is a > bad thing this one can definitely be changed. :) > > -- Mads > > On Tue, Jul 13, 2010 at 5:27 PM, Adam Barth <[email protected]> wrote: >> Then this should be an easy fix. Here are the two error messages: >> >> == JSC == >> >> CONSOLE MESSAGE: line 1: SyntaxError: Parse error >> >> == V8 == >> >> CONSOLE MESSAGE: line 1: Uncaught SyntaxError: Unexpected token < >> >> In this case, V8 is providing too much information to the web platform >> about the error. I haven't checked, but if V8 provides the same level >> of detail for for external scripts, it's possible that this is a >> security and/or privacy problem. >> >> Adam >> >> >> On Tue, Jul 13, 2010 at 6:15 AM, Mads Ager <[email protected]> wrote: >>> >>> Hi Peter, >>> >>> i understand the pain and we have actually changed some of our error >>> messages to match what JSC is doing for this reason. >>> >>> However, V8 and JSC are just different and sometimes do not have the >>> same information available when throwing exceptions and it is >>> unreasonable to think that we can completely align. >>> >>> We can have a pass over the error messages again and see if there are >>> some easy to fix things. >>> >>> Cheers, -- Mads >>> >>> On Mon, Jul 5, 2010 at 4:11 AM, Peter Kasting <[email protected]> wrote: >>> > Hi V8 folks, >>> > V8's error messages differ slightly from JSC's. This is a problem because >>> > it means that we Chromium WebKit folks are continually having to analyze >>> > and >>> > re-update platform-specific "expected test output" files which include >>> > output from the JS engine. >>> > One example of this is WebKit/LayoutTests/html5lib/runner.html, which >>> > changes daily (or even more rapidly) and thus has resulted in a lot of >>> > work >>> > for us for a very long time. We have to maintain several 5000-line-long >>> > expectation files just for Chromium because of a single error message >>> > difference: "SyntaxError: Parse error" vs. "Uncaught SyntaxError: >>> > Unexpected >>> > token <". And that's just one example. I hope you can imagine why not >>> > only >>> > doing this, but explaining the situation to each new WebKit sheriff, ends >>> > up >>> > costing us in significant, ongoing ways. >>> > Furthermore, it's wrong for these engines' outputs to differ in ways that >>> > web authors can detect anyway. When Safari and Chromium differ in other >>> > ways, we seek to converge the two, because web authors need to be able to >>> > treat the two identically. Here it's the same: I don't have a vested >>> > interest in which engine's messages "win", but the two need to converge. >>> > I'm told this issue has come up before and there's been pushback that "we >>> > like our error messages". I'm sorry, but this isn't sufficient >>> > justification for these kinds of differences. >>> > It seems like it should be a fairly easy change to make the error outputs >>> > match, and if there's significant value in V8's text over JSC's, to first >>> > make the two match and then file bugs to improve both engines' messages >>> > simultaneously. If I'm missing something, please explain what; otherwise, >>> > I'd like to hear a plan for how this can happen, or be told against whom I >>> > should file an appropriate bug. >>> > Thanks, >>> > PK >>> > >>> > -- >>> > v8-dev mailing list >>> > [email protected] >>> > http://groups.google.com/group/v8-dev >> > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
