Bug 46804 – Web Inspector: to add V8 protocol support for JS engine

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

[Mikołaj Małecki]

We are working on providing v8 debugging protocol for JavaScript engine.  This will be currently interfaced only from EFL Port (although it may fit other ports as well). It will make it possible to send commands and receive responses/events of V8 debugger protocol using public WebKit API for specified port.
 
We're going to make changes mainly in EFL WebCoreSupport (adding an alternative class to InspectorClientEfl), but we'll need to make changes in WebCore, too (in order to make available various data that we need to implement the protocol translator).

If anyone knows whether there are works being done about such a feature, please comment this bug in order to prevent prospective "feature conflicts".

[Pavel Feldman]

We, the Web Inspector team are going the opposite direction. We are deprecating V8 protocol as a part of Chromium and are migrating to the new Web Inspector protocol that we are introducing. We also own Chromium DevTools and are V8 contributors. I think we should sync up.

[Mikołaj Małecki]

I think even though Web Inspector protocol will be used, both V8 protocol manager and WI protocol manager can coexist, so it should be easy for us to sync up.

We (ok, we, Samsung) need this V8 protocol because we need that WebKit-EFL cooperate with other software that is using V8 debugger protocol.

Changes that we need to do in WebCore are just to "make our work easier", that is, to be able to perform particular activities in "inspector", needed by V8 protocol, quick and easy way. Can you tell me whether there is any strategy for interfacing inspector so that we won't violate any rules concerning that?

[Pavel Feldman]

(In reply to comment #2)
> I think even though Web Inspector protocol will be used, both V8 protocol manager and WI protocol manager can coexist, so it should be easy for us to sync up.
> 
> We (ok, we, Samsung) need this V8 protocol because we need that WebKit-EFL cooperate with other software that is using V8 debugger protocol.
> 
> Changes that we need to do in WebCore are just to "make our work easier", that is, to be able to perform particular activities in "inspector", needed by V8 protocol, quick and easy way. Can you tell me whether there is any strategy for interfacing inspector so that we won't violate any rules concerning that?

The strategy is that you can't add anything into WebCore that is not used by WebCore itself or the WebKit ports. I'd like to learn what other tools you'd like to use against V8. If that is Eclipse integration, then it is also us who are doing it and it is also going the Web Inspector way. If you are still keen on using v8 protocol, you should be able to do it from within your webkit port.

[Mikołaj Małecki]

I don't know much about this tool but that it is running on Eclipse and communicates with V8 debugger protocol over sockets.

I think debugger functionalities are common enough that if you are going to provide some other protocol support for Web Inspector, this should cover rather the same functionality.

Example things that we need that WebInspector API provide us with are:
 - access to page's scripts information (on request)
 - current stack frame and backtrace information
 - interface for evaluating expressions
 - modification of a single breakpoint (enable/disable, skips, condition)

These above things are not available currently or obtaining this information is complicated (in particular, usually needs caching particular information - they can be only caught by events, but not accessed when there is a need to obtain them).

Can you explain me this "Web Inspector way"?

[Pavel Feldman]

(In reply to comment #4)
> I don't know much about this tool but that it is running on Eclipse and communicates with V8 debugger protocol over sockets.
> 

http://code.google.com/p/chromedevtools/ - this is the one I am talking about.

> I think debugger functionalities are common enough that if you are going to provide some other protocol support for Web Inspector, this should cover rather the same functionality.
> 
> Example things that we need that WebInspector API provide us with are:
>  - access to page's scripts information (on request)
>  - current stack frame and backtrace information
>  - interface for evaluating expressions
>  - modification of a single breakpoint (enable/disable, skips, condition)
> 

Given that Web Inspector is working over Web Inspector protocol, it surely covers these and much more.

> These above things are not available currently or obtaining this information is complicated (in particular, usually needs caching particular information - they can be only caught by events, but not accessed when there is a need to obtain them).
> 

We will need to fix these one by one, in fact I am eager to get an example.

> Can you explain me this "Web Inspector way"?

More info available in https://bugs.webkit.org/show_bug.cgi?id=43732
You should look at WebCore/inspector/inspector.idl (http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/inspector/Inspector.idl&q=inspector.idl&exact_package=chromium&sa=N&cd=1&ct=rc).

[Pavel Feldman]

We are exposing Web Inspector protocol instead, deprecating V8 protocol as the main one for Chrome.