[Webkit-unassigned] [Bug 166680] [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 21 12:21:04 PDT 2017


--- Comment #14 from Joseph Pecoraro <joepeck at webkit.org> ---
Comment on attachment 307373
  --> https://bugs.webkit.org/attachment.cgi?id=307373
Rebased patch

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

> Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorGlib.cpp:250
> +        // Don't allow automatic inspection unless it is allowed or we are stopped.
> +        if (!m_automaticInspectionEnabled || !m_enabled) {
> +            pushListingsSoon();
> +            return;
> +        }

Given currently m_automaticInspectionEnabled will always be false this path will always be taken and the rest of this method is unreachable code.

You might just want a comment here about Implementing automatic inspection (like the comment below).

>> Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorGlib.cpp:254
>> +        // Multiple attempts on the same thread should not be possible because our nested run loop is in a special RWI mode.
> Why is it not important to fix this before landing?

This matches the Cocoa port. It hasn't been a common scenario for people using the JavaScriptCore APIs so its not received much priority for fixing. And again this is only for the automatic inspection case.

>> Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorGlib.cpp:298
>> +    // FIXME: Implement automatic inspection.
> What's automatic inspection? This is different from automated inspection?

Automatic inspection (as implementing in the Cocoa version of RemoteInspector) is the ability for a debugger to immediately be offered to attach to a debuggable target as soon as the target is registered.

An example using the JavaScriptCore ObjC API. An application may have code like the following:

    [[JSContext alloc] init] evaluateScript:@"var a = 1; var b = 2; oopsReferenceError; var c = a + b;"];

Safari can still have opened a remote inspector for this JSContext and step through that initial evaluation.

This is done by:

  • Remote debuggers indicating with some global system state that there is an automatic inspection client
  • Here in updateAutomaticInspectionCandidate if that global system state is true => go through the automatic inspection candidate process
    - during in this process we pause the application and ask remote debuggers (in order) if they want to debug this or not
    - we also have a timeout (the dispatch after above) to unpause the app if the remote debuggers did not respond.

On Mac we only use this for automatically debugging JSContexts to handle the situation shown above. And not uncommon for a JSContext to be created for a single evaluation and never used again (like the above example), so we needed to have a way to handle that debugging scenario. I believe on GTK this is being used more for Web Driver, so automatic inspection is not necessary. It may be a future feature of interest.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170421/76825ee5/attachment-0001.html>

More information about the webkit-unassigned mailing list