Bug 86861 - Web Inspector: Expose function (closure) scopes in remote protocol
Summary: Web Inspector: Expose function (closure) scopes in remote protocol
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-18 09:26 PDT by Peter Rybin
Modified: 2012-05-30 01:41 PDT (History)
15 users (show)

See Also:


Attachments
Patch (15.31 KB, patch)
2012-05-21 13:07 PDT, Peter Rybin
no flags Details | Formatted Diff | Diff
Patch (28.05 KB, patch)
2012-05-22 20:29 PDT, Peter Rybin
no flags Details | Formatted Diff | Diff
All but excpected file for JSC (25.95 KB, patch)
2012-05-24 14:49 PDT, Peter Rybin
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-02 (566.89 KB, application/zip)
2012-05-24 17:34 PDT, WebKit Review Bot
no flags Details
Patch (27.82 KB, patch)
2012-05-26 17:03 PDT, Peter Rybin
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-01 (541.56 KB, application/zip)
2012-05-26 20:22 PDT, WebKit Review Bot
no flags Details
Archive of layout-test-results from ec2-cr-linux-04 (625.52 KB, application/zip)
2012-05-26 21:08 PDT, WebKit Review Bot
no flags Details
with sorted properties (27.85 KB, patch)
2012-05-27 15:45 PDT, Peter Rybin
no flags Details | Formatted Diff | Diff
rebase (27.85 KB, patch)
2012-05-28 07:01 PDT, Peter Rybin
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Rybin 2012-05-18 09:26:01 PDT
Each function in JavaScript is a closure. However currently remote protocol doesn't let see the internal scope of function. It only gets visible when function is activated (as a call frame variables).
Since the variables are always there, make them accessible via FunctionDetails structure.
Comment 1 Peter Rybin 2012-05-21 13:07:12 PDT
Created attachment 143084 [details]
Patch
Comment 2 Yury Semikhatsky 2012-05-21 23:00:33 PDT
Comment on attachment 143084 [details]
Patch

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

We will need a test for this change. See LayoutTests/inspector/debugger/function-details.html

> Source/WebCore/bindings/v8/ScriptDebugServer.h:117
> +// V8-specific interface section.

Just move the method to the public section above. The comment should be more detailed, otherwise it is confusing as there are other v8-specific methods already. I'd just drop the comment.

> Source/WebCore/bindings/v8/custom/V8InjectedScriptHostCustom.cpp:188
> +    InjectedScriptHost* host = V8InjectedScriptHost::toNative(args.Holder());

What would it take to support this for JSC as well? If you can't implement it for JSC, please file a bug and put FIXME with the bug # in the corresponding JS bindings.

> Source/WebCore/inspector/InjectedScriptHost.cpp:186
> +ScriptDebugServer& InjectedScriptHost::getScriptDebugServer()

We don't use get prefixes in WebKit, simply scriptDebugServer()

> Source/WebCore/inspector/InjectedScriptSource.js:215
> +                // FIXME: fix group id

Group id should be passed as a parameter of the protocol command.

> Source/WebCore/inspector/InjectedScriptSource.js:545
> +InjectedScript.CallFrameProxy._createScopeJson = (function() {

No need to use extra closure here. If you are concerned about the performance you may move the types map to InjectedScript.CallFrameProxy.ScopeTypeNames.

> Source/WebCore/inspector/InjectedScriptSource.js:559
> +    return function(scope_type_code, scope_object, group_id) {

style: use camelCase for variable names
Comment 3 Pavel Feldman 2012-05-21 23:04:09 PDT
Comment on attachment 143084 [details]
Patch

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

> Source/WebCore/bindings/v8/DebuggerScript.js:70
> +        return void 0;

we don't use such notation, simply return here instead.

> Source/WebCore/bindings/v8/ScriptDebugServer.h:117
> +// V8-specific interface section.

You don't need this annotation in the header under bindings/v8. You should also keep this method private to the debug server for the encapsulation purposes.

> Source/WebCore/bindings/v8/custom/V8InjectedScriptHostCustom.cpp:191
> +    v8::Handle<v8::Value> scopes = debugServer.callDebuggerMethod("getFunctionScopes", 1, argv);

Should be debugServer.functionScopes(blah).

> Source/WebCore/bindings/v8/custom/V8InjectedScriptHostCustom.cpp:193
> +        result->Set(v8::String::New("scopes_raw"), scopes);

rawScopes ?

> Source/WebCore/inspector/InjectedScriptHost.cpp:188
> +    return m_debuggerAgent->scriptDebugServer();

You should be careful about accessing debugServer before debug domain is enabled and scripts are sent to the front-end. This won't work.
Comment 4 Yury Semikhatsky 2012-05-21 23:15:28 PDT
Comment on attachment 143084 [details]
Patch

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

>> Source/WebCore/bindings/v8/DebuggerScript.js:70
>> +        return void 0;
> 
> we don't use such notation, simply return here instead.

return null would be more consistent with the rest code as this function is expected to return a value.
Comment 5 Peter Rybin 2012-05-22 19:47:04 PDT
(In reply to comment #2)
> (From update of attachment 143084 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=143084&action=review
> 
> We will need a test for this change. See LayoutTests/inspector/debugger/function-details.html

function-details is extended. Will be a problem with JSC builds? Do we do any kind of conditioning for V8/JSC?
 
> > Source/WebCore/bindings/v8/ScriptDebugServer.h:117
> > +// V8-specific interface section.
> 
> Just move the method to the public section above. The comment should be more detailed, otherwise it is confusing as there are other v8-specific methods already. I'd just drop the comment.

You said we have polymorphic part and V8-specific part. Should we keep it clear? Anyway, the method is redone now.

> > Source/WebCore/bindings/v8/custom/V8InjectedScriptHostCustom.cpp:188
> > +    InjectedScriptHost* host = V8InjectedScriptHost::toNative(args.Holder());
> What would it take to support this for JSC as well? If you can't implement it for JSC, please file a bug and put FIXME with the bug # in the corresponding JS bindings.

I made a bug and added FIXME. I haven't investigated JSC yet on this.

> > Source/WebCore/inspector/InjectedScriptHost.cpp:186
> > +ScriptDebugServer& InjectedScriptHost::getScriptDebugServer()
> We don't use get prefixes in WebKit, simply scriptDebugServer()

Done

> > Source/WebCore/inspector/InjectedScriptSource.js:215
> > +                // FIXME: fix group id
> Group id should be passed as a parameter of the protocol command.
The comment was obsolete. Sorry about this. I inherit group id from the function id (similar to how getProperties works I believe).

> > Source/WebCore/inspector/InjectedScriptSource.js:545
> > +InjectedScript.CallFrameProxy._createScopeJson = (function() {
> No need to use extra closure here. If you are concerned about the performance you may move the types map to InjectedScript.CallFrameProxy.ScopeTypeNames.

Old approach restored.

> > Source/WebCore/inspector/InjectedScriptSource.js:559
> > +    return function(scope_type_code, scope_object, group_id) {
> style: use camelCase for variable names
Done
Comment 6 Peter Rybin 2012-05-22 19:51:31 PDT
> > Source/WebCore/bindings/v8/DebuggerScript.js:70
> > +        return void 0;
> we don't use such notation, simply return here instead.
Done

> > Source/WebCore/bindings/v8/ScriptDebugServer.h:117
> > +// V8-specific interface section.
> You don't need this annotation in the header under bindings/v8. You should also keep this method private to the debug server for the encapsulation purposes.

Yury said you have cross-engine polymorphic interface part and the engine-specific part. Wanted to keep it clear.
Removed now.

> > Source/WebCore/bindings/v8/custom/V8InjectedScriptHostCustom.cpp:191
> > +    v8::Handle<v8::Value> scopes = debugServer.callDebuggerMethod("getFunctionScopes", 1, argv);
> Should be debugServer.functionScopes(blah).
Done

> > Source/WebCore/bindings/v8/custom/V8InjectedScriptHostCustom.cpp:193
> > +        result->Set(v8::String::New("scopes_raw"), scopes);
> rawScopes ?
Done

> > Source/WebCore/inspector/InjectedScriptHost.cpp:188
> > +    return m_debuggerAgent->scriptDebugServer();
> You should be careful about accessing debugServer before debug domain is enabled and scripts are sent to the front-end. This won't work.

This is still and issue.
Comment 7 Peter Rybin 2012-05-22 19:51:59 PDT
(In reply to comment #4)
> (From update of attachment 143084 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=143084&action=review
> 
> >> Source/WebCore/bindings/v8/DebuggerScript.js:70
> >> +        return void 0;
> > 
> > we don't use such notation, simply return here instead.
> 
> return null would be more consistent with the rest code as this function is expected to return a value.

Done
Comment 8 Peter Rybin 2012-05-22 20:29:20 PDT
Created attachment 143441 [details]
Patch
Comment 9 Yury Semikhatsky 2012-05-23 05:27:11 PDT
Comment on attachment 143441 [details]
Patch

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

> Source/WebCore/bindings/v8/DebuggerScript.js:69
> +    if (count == 0) {

style nit: no need for {} around 1-line statement

> Source/WebCore/bindings/v8/DebuggerScript.js:297
> +    case ScopeType.Catch:

You will need to rebaseline after http://trac.webkit.org/changeset/118161

> Source/WebCore/bindings/v8/ScriptDebugServer.cpp:411
> +

Please revert this.

> Source/WebCore/inspector/InjectedScriptHost.cpp:188
> +    // FIX BEFORE COMMIT: (pfeldman) You should be careful about accessing debugServer before debug domain is enabled and scripts are sent to the front-end. This won't work.

r- for this.

> Source/WebCore/inspector/InjectedScriptHost.h:52
> +class ScriptDebugServer;

Mind sorting order.

> Source/WebCore/inspector/InjectedScriptHost.h:126
> +    InspectorDebuggerAgent* m_debuggerAgent;

It should be guarded with #if ENABLE(JAVASCRIPT_DEBUGGER)

> Source/WebCore/inspector/InjectedScriptSource.js:211
> +            var scopes_raw = details.rawScopes;

style nit: scopes_raw -> scopesRaw

> Source/WebCore/inspector/InjectedScriptSource.js:214
> +            for (var i = 0; i < scopes_raw.length; i++) {

style nit: no need for {}

> LayoutTests/http/tests/inspector/debugger-test.js:63
> +        if (!caseName) {

style nit: no need for {}

> LayoutTests/http/tests/inspector/inspector-test.js:248
> +        var caseName = nextTest.testCaseName;

Please revert this and adhere to the style used in the existing inspector tests. Instead of calling 
  createStandardTestCase("firstLineFunction", "testGetFirstLineFunctionDetails")
below you could do something like 

InspectorTest.runDebuggerTestSuite([
    function testGetFirstLineFunctionDetails(next)
    {
        dumpScopesForExpression("firstLineFunction", next);
    },
...
]);

> LayoutTests/inspector/debugger/function-details-expected.txt:9
> +columnNumber: 36

JSC doesn't provide column number, you should update this file with new JSC results and LayoutTests/platform/chromium/inspector/debugger/function-details-expected.txt with new Chromium test results.

> LayoutTests/inspector/debugger/function-details.html:68
> +            var var_array = [];

style: camelCase for variable names

> LayoutTests/inspector/debugger/function-details.html:70
> +                d = propertyDescriptors[i];

var d = ...

> LayoutTests/inspector/debugger/function-details.html:73
> +                    if (d.value.value) {

style nit: no need for {}
Comment 10 Peter Rybin 2012-05-24 14:49:32 PDT
Created attachment 143902 [details]
All but excpected file for JSC
Comment 11 WebKit Review Bot 2012-05-24 17:34:20 PDT
Comment on attachment 143902 [details]
All but excpected file for JSC

Attachment 143902 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12799338

New failing tests:
inspector/debugger/function-details.html
Comment 12 WebKit Review Bot 2012-05-24 17:34:26 PDT
Created attachment 143932 [details]
Archive of layout-test-results from ec2-cr-linux-02

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 13 Yury Semikhatsky 2012-05-25 03:04:24 PDT
Comment on attachment 143902 [details]
All but excpected file for JSC

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

> Source/WebCore/inspector/InjectedScriptHost.h:131
> +#if ENABLE(JAVASCRIPT_DEBUGGER)

Wrong field is guarded.

> LayoutTests/inspector/debugger/function-details.html:127
> +            return Function.prototype.toString.call(this).replace("UnnamedTestCase", name);

I still don't understand the reason for this complication while we can follow the same style that is used in other inspector tests.
Comment 14 Peter Rybin 2012-05-26 17:03:10 PDT
Created attachment 144211 [details]
Patch
Comment 15 WebKit Review Bot 2012-05-26 20:21:58 PDT
Comment on attachment 144211 [details]
Patch

Attachment 144211 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12799938

New failing tests:
inspector/debugger/function-details.html
Comment 16 WebKit Review Bot 2012-05-26 20:22:03 PDT
Created attachment 144212 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 17 WebKit Review Bot 2012-05-26 21:08:30 PDT
Comment on attachment 144211 [details]
Patch

Attachment 144211 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12791942

New failing tests:
inspector/debugger/function-details.html
Comment 18 WebKit Review Bot 2012-05-26 21:08:35 PDT
Created attachment 144213 [details]
Archive of layout-test-results from ec2-cr-linux-04

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 19 Peter Rybin 2012-05-27 15:45:18 PDT
Created attachment 144246 [details]
with sorted properties
Comment 20 WebKit Review Bot 2012-05-28 01:03:30 PDT
Comment on attachment 144246 [details]
with sorted properties

Rejecting attachment 144246 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2

Last 500 characters of output:
commit-queue/Source/WebKit/chromium/third_party/v8-i18n --revision 104 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
47>At revision 104.

________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'

________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
Updating webkit projects from gyp files...

Full output: http://queues.webkit.org/results/12845138
Comment 21 Peter Rybin 2012-05-28 07:01:02 PDT
Created attachment 144352 [details]
rebase
Comment 22 WebKit Review Bot 2012-05-28 08:52:21 PDT
Comment on attachment 144352 [details]
rebase

Clearing flags on attachment: 144352

Committed r118685: <http://trac.webkit.org/changeset/118685>
Comment 23 WebKit Review Bot 2012-05-28 08:52:28 PDT
All reviewed patches have been landed.  Closing bug.
Comment 24 Yury Semikhatsky 2012-05-30 01:41:59 PDT
(In reply to comment #22)
> (From update of attachment 144352 [details])
> Clearing flags on attachment: 144352
> 
> Committed r118685: <http://trac.webkit.org/changeset/118685>

This change broke compilation of InjectedScriptSource.js:


Compiling InjectedScriptSource.js...
Source/WebCore/inspector/InjectedScriptSource.js:32: WARNING - Suspicious code. This code lacks side-effects. Is there a bug?
(function (InjectedScriptHost, inspectedWindow, injectedScriptId) {
 ^

Source/WebCore/inspector/InjectedScriptSource.js:203: WARNING - Property rawScopes never defined on details
            var rawScopes = details.rawScopes;
                            ^

Source/WebCore/inspector/InjectedScriptSource.js:205: WARNING - Property rawScopes never defined on details
            delete details.rawScopes;
                   ^

0 error(s), 3 warning(s), 66.0% typed