Bug 115242 – Web Inspector: expose the JS parser to the protocol

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Timothy Hatcher]

We should add RuntimeAgent.parse to get access to parse errors for use in the console prompt.

[Timothy Hatcher]

Created attachment 199811 [details]
Patch

[Early Warning System Bot]

Comment on attachment 199811 [details]
Patch

Attachment 199811 [details] did not pass qt-ews (qt):
Output: http://webkit-queues.appspot.com/results/43804

[EFL EWS Bot]

Comment on attachment 199811 [details]
Patch

Attachment 199811 [details] did not pass efl-wk2-ews (efl-wk2):
Output: http://webkit-queues.appspot.com/results/236076

[EFL EWS Bot]

Comment on attachment 199811 [details]
Patch

Attachment 199811 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/26979

[Early Warning System Bot]

Comment on attachment 199811 [details]
Patch

Attachment 199811 [details] did not pass qt-wk2-ews (qt-wk2):
Output: http://webkit-queues.appspot.com/results/226170

[Build Bot]

Comment on attachment 199811 [details]
Patch

Attachment 199811 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/126369

[Timothy Hatcher]

Created attachment 199818 [details]
Patch

[Build Bot]

Comment on attachment 199818 [details]
Patch

Attachment 199818 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/126394

[Timothy Hatcher]

Created attachment 199838 [details]
Patch

[Build Bot]

Comment on attachment 199838 [details]
Patch

Attachment 199838 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/65425

[Timothy Hatcher]

Created attachment 199841 [details]
Patch

[Timothy Hatcher]

Comment on attachment 199841 [details]
Patch

Need to fix Windows build before landing.

[Timothy Hatcher]

Created attachment 199844 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 199844 [details]
Patch

Clearing flags on attachment: 199844

Committed r149202: <http://trac.webkit.org/changeset/149202>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Joseph Pecoraro]

Comment on attachment 199844 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=199844&action=review

Nice!

> Source/WebCore/inspector/Inspector.json:671
> +                "description": "Syntax error type: \"none\" for no error, \"irrecoverable\" for unrecoverable errors, \"unterminated-literal\" for when there is an unterminated literal, \"recoverable\" for when the expression is unfinished but valid so far."

Some of the descriptions have <code>foo</code> instead of \"foo\". I think its easier to read the <code> versions. Maybe one day we can format this file as documentation nicely, like: <https://developers.google.com/chrome-developer-tools/docs/protocol/tot/console>

> Source/WebCore/inspector/InspectorRuntimeAgent.cpp:99
> +    checkSyntax(*vm, JSC::makeSource(expression), error);

When on a breakpoint, we may want to inherit the Strict versus Non-Strict mode scope we are in and pass that into checkSyntax, which currently hardcodes JSParseNormal. There are syntax errors that can happen in strict mode that can't in normal mode, e.g. duplicate object literal keys:

    js> var o = { x:1, x:2 }; o.x
    2

    js> "use strict"; var o = { x:1, x:2 }; o.x
    Exception: SyntaxError: Unexpected token '}'

I can file a follow-up bug on this edge case.

> Source/WebCore/inspector/InspectorRuntimeAgent.h:64
> +    virtual void parse(ErrorString*, const String& expression, TypeBuilder::Runtime::SyntaxErrorType::Enum* result, TypeBuilder::OptOutput<String>* message, RefPtr<TypeBuilder::Runtime::ErrorRange>&);

We should consider starting to add OVERRIDE to these, to help catch dead code if a protocol method is removed (rare or accidental), the compiler can tell us.