[webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

[Pavel Feldman]

An update.

Pavel

WebKit Remote Debugging <http://www.webkit.org/blog/?p=1620>Posted by *Pavel
Feldman* on Saturday, April 30th, 2011 at 1:53 am

As you might know, WebKit Web Inspector (aka Chrome Developer Tools) is
implemented as an HTML + CSS + JavaScript web application. What you might
not know is that Web Inspector can run outside of the rendering engine
environment and still provide complete set of its features to the end user.
Debugging over the wire

Running debugger outside the rendering engine is interesting because mobile
platforms do not often provide enough screen real estate for quality
debugging; they have network stack and CPU specifics that often affect page
load and runtime. Still, they are based on the WebCore rendering engine,
they could have Web Inspector instrumentation running and hence expose
valuable debugging information to the end user. Now that Web Inspector is
functioning out-of-process over the serialized-message-channel, attaching
Web Inspector window to the remote rendering engine is possible. Here is an
example of the remote debugging session using Chrome Developer Tools:

1. Start your target browser (recent Chromium build or Google Chrome will
do) with the remote-debugging-port command line switch:

Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222

2. Open several pages there.

3. Navigate to the given port from your client browser instance (WebKit
nightly or another Chrome instance will do) and it will list inspectable
pages opened in the browser as web links.
[image: Tab discovery page]

4. Follow any of these links to start remote debugging session for the
corresponding page.
[image: Tab attached page]

You will find remote debugging interface very similar to the Web Inspector /
Chrome Developer Tools and here is why:

   - Target Chrome browser acts as a web server bound to the port 9222 on
   the localhost.
   - Once you follow the link, your client browser fetches HTML, JavaScript
   and CSS files of the Developer Tools front-end over HTTP.
   - Upon load event, Developer Tools establishes Web Socket connection back
   to the target browser and starts interchanging JSON messages with it.

In fact, pretty much the same scenario takes place within any WebKit-based
browser when user opens Web Inspector. The only difference is that the
transports being used for the JSON message interchange may vary. Note, that
in case of mobile devices, front-end files can also be served from the
cloud.
Remote Debugging Protocol

Another scenario for remote debugging is IDE integration. Web IDEs would
like to provide seamless debugging experience integrated into their
environments to the end user. Exposing unified WebKit remote debugging
protocol would allow them to use alternate front-ends for the WebKit
debugging.

Under the hood, Web Inspector front-end is talking to the browser backend by
means of the Remote Debugging Protocol. This protocol is based on the JSON-RPC
2.0 <http://groups.google.com/group/json-rpc/web/json-rpc-2-0> specification.
It is bidirectional: clients send asynchronous requests to the server,
server responds to these requests and/or generates notifications. Since API
surface for general purpose web debugging is huge, we divided it into a
number of domains. Each domain contains requests and notifications specific
to some area. Here is the list of the domains supported so far:

   - *Browser Debugger* – allows setting breakpoints on particular DOM
   operations and events. JavaScript execution will stop on these operations as
   if there was a regular breakpoint set.
   - *Console* – defines methods and events for interaction with the
   JavaScript console.
   - *CSS* – exposes raw CSS read / write operations.
   - *Debugger* – exposes JavaScript debugging functions; allows setting and
   removing breakpoints, stepping through execution, exploring stack traces,
   etc.
   - *DOM* – This domain exposes DOM read/write operations.
   - *Network* – allows tracking network activities of the page; exposes
   information about HTTP and WebSocket requests and responses, their headers,
   bodies, raw timing, etc.
   - *Page* – actions and events related to the inspected page.
   - *Runtime* – exposes JavaScript runtime by means of remote evaluation
   and mirror objects.
   - *Timeline* – provides its clients with instrumentation records that are
   generated during the page runtime.

You can find JSON schema defining the protocol
here<http://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json>.
For your convenience, we generated documentation from this schema and
published it on the Chrome DevTools
page<http://code.google.com/chrome/devtools/docs/remote-debugging.html>.
Note that there are few unlisted domains such as Application Cache, DOM
Storage, and Database, but they are not ready for the prime time yet.
What’s next

We are now open to the feedback on the WebKit Remote Debugging Protocol. We
will collect all the feedback in the form of the bug
reports<http://webkit.org/new-inspector-bug> and
the Chrome DevTools
forum<http://groups.google.com/group/google-chrome-developer-tools>
messages.
We will then address initial feedback, polish the protocol a bit and publish
its first draft with a specific version. Once we have the protocol defined,
developers can come up with the alternate front-ends (IDEs and such) that
will interact with the WebKit instrumentation running in various browsers.
We also expect all the WebKit ports to expose WebSocket interfaces similar
to explained above or to come up with any other transport and bridge it with
the Web Inspector front-end. Stay tuned!
- Show quoted text -

Comments are closed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110430/693d08a0/attachment.html>