[webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Pavel Feldman
pfeldman at chromium.org
Fri Apr 29 13:00:44 PDT 2011
Surfin' Safari
<< Web Inspector: Understanding Stack
Traces<http://www.webkit.org/blog/1544/web-inspector-understanding-stack-traces/>
Remote Debugging with Web Inspector <http://www.webkit.org/blog/?p=1620>Posted
by *Pavel Feldman* on Friday, April 29th, 2011 at 12:59 pm
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.
Running outside the page context (and browser) 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 have Web Inspector backend instrumentation running and they can expose
valuable debugging information to the user.
Another scenario for remote debugging is IDE integration. Web IDEs would
like to provide seamless debugging experience, integrated into their
environments to the user. Exposing unified WebKit remote debugging protocol
will allow them to use alternate front-ends for the WebKit debugging.
Here is an example of the remote debugging session using Chrome Developer
Tools:
Debugging over the wire
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. Navigate to the given port from your client browser instance (WebKit
nightly or another Chrome instance will do) and it will list inspectable
pages as web links.
[image: Tab discovery page]
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
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 serves responses to these requests and 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 at the moment:
- *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 the first draft.
- 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 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 to the Web Inspector front-end.
You can follow any responses to this entry through the RSS
2.0<http://www.webkit.org/blog/?p=1620/feed/> feed.
Both comments and pings are currently closed. Edit this
entry.<http://www.webkit.org/blog/wp-admin/post.php?action=edit&post=1620>
Comments are closed.
- Home <http://www.webkit.org/>
- Surfin’ Safari Blog <http://www.webkit.org/blog/>
- Planet WebKit <http://planet.webkit.org/>
- Project Goals <http://www.webkit.org/projects/goals.html>
- Keeping in Touch <http://www.webkit.org/contact.html>
- Trac <http://trac.webkit.org/>
- Contributors Meeting <http://www.webkit.org/meeting/>
- Working with the Code
- Installing Developer Tools <http://www.webkit.org/building/tools.html>
- Getting the Code <http://www.webkit.org/building/checkout.html>
- Building WebKit <http://www.webkit.org/building/build.html>
- Running WebKit <http://www.webkit.org/building/run.html>
- Debugging WebKit <http://www.webkit.org/building/debug.html>
- Contributing Code <http://www.webkit.org/coding/contributing.html>
- Commit and Review
Policy<http://www.webkit.org/coding/commit-review-policy.html>
- Security Policy <http://www.webkit.org/security/>
- Documentation
- Wiki <http://trac.webkit.org/wiki>
- Projects <http://www.webkit.org/projects/>
- Code Style Guidelines <http://www.webkit.org/coding/coding-style.html>
- Technical Articles<http://www.webkit.org/coding/technical-articles.html>
- Web Inspector <http://trac.webkit.org/wiki/WebInspector>
- Web Developer Resources <http://trac.webkit.org/wiki/WebDevelopers>
- Demos <http://www.webkit.org/demos/>
- Testing
- Regression Testing <http://www.webkit.org/quality/testing.html>
- Leak Hunting <http://www.webkit.org/quality/leakhunting.html>
- Writing New Tests <http://www.webkit.org/quality/testwriting.html>
- Getting a Crash Log <http://www.webkit.org/quality/crashlogs.html>
- Bugs
- Reporting Bugs <http://www.webkit.org/quality/reporting.html>
- Bug Report Guidelines <http://www.webkit.org/quality/bugwriting.html>
- Bug Prioritization <http://www.webkit.org/quality/bugpriorities.html>
- Test Case Reduction <http://www.webkit.org/quality/reduction.html>
- Bug Life Cycle <http://www.webkit.org/quality/lifecycle.html>
- Archives
- April 2011 <http://www.webkit.org/blog/date/2011/04/>
- March 2011 <http://www.webkit.org/blog/date/2011/03/>
- February 2011 <http://www.webkit.org/blog/date/2011/02/>
- January 2011 <http://www.webkit.org/blog/date/2011/01/>
- December 2010 <http://www.webkit.org/blog/date/2010/12/>
- September 2010 <http://www.webkit.org/blog/date/2010/09/>
- August 2010 <http://www.webkit.org/blog/date/2010/08/>
- July 2010 <http://www.webkit.org/blog/date/2010/07/>
- June 2010 <http://www.webkit.org/blog/date/2010/06/>
- May 2010 <http://www.webkit.org/blog/date/2010/05/>
- April 2010 <http://www.webkit.org/blog/date/2010/04/>
- March 2010 <http://www.webkit.org/blog/date/2010/03/>
- February 2010 <http://www.webkit.org/blog/date/2010/02/>
- January 2010 <http://www.webkit.org/blog/date/2010/01/>
- December 2009 <http://www.webkit.org/blog/date/2009/12/>
- November 2009 <http://www.webkit.org/blog/date/2009/11/>
- October 2009 <http://www.webkit.org/blog/date/2009/10/>
- September 2009 <http://www.webkit.org/blog/date/2009/09/>
- July 2009 <http://www.webkit.org/blog/date/2009/07/>
- June 2009 <http://www.webkit.org/blog/date/2009/06/>
- May 2009 <http://www.webkit.org/blog/date/2009/05/>
- April 2009 <http://www.webkit.org/blog/date/2009/04/>
- March 2009 <http://www.webkit.org/blog/date/2009/03/>
- February 2009 <http://www.webkit.org/blog/date/2009/02/>
- December 2008 <http://www.webkit.org/blog/date/2008/12/>
- October 2008 <http://www.webkit.org/blog/date/2008/10/>
- September 2008 <http://www.webkit.org/blog/date/2008/09/>
- June 2008 <http://www.webkit.org/blog/date/2008/06/>
- May 2008 <http://www.webkit.org/blog/date/2008/05/>
- April 2008 <http://www.webkit.org/blog/date/2008/04/>
- March 2008 <http://www.webkit.org/blog/date/2008/03/>
- February 2008 <http://www.webkit.org/blog/date/2008/02/>
- January 2008 <http://www.webkit.org/blog/date/2008/01/>
- December 2007 <http://www.webkit.org/blog/date/2007/12/>
- November 2007 <http://www.webkit.org/blog/date/2007/11/>
- October 2007 <http://www.webkit.org/blog/date/2007/10/>
- September 2007 <http://www.webkit.org/blog/date/2007/09/>
- August 2007 <http://www.webkit.org/blog/date/2007/08/>
- July 2007 <http://www.webkit.org/blog/date/2007/07/>
- June 2007 <http://www.webkit.org/blog/date/2007/06/>
- May 2007 <http://www.webkit.org/blog/date/2007/05/>
- April 2007 <http://www.webkit.org/blog/date/2007/04/>
- March 2007 <http://www.webkit.org/blog/date/2007/03/>
- February 2007 <http://www.webkit.org/blog/date/2007/02/>
- January 2007 <http://www.webkit.org/blog/date/2007/01/>
- December 2006 <http://www.webkit.org/blog/date/2006/12/>
- November 2006 <http://www.webkit.org/blog/date/2006/11/>
- October 2006 <http://www.webkit.org/blog/date/2006/10/>
- September 2006 <http://www.webkit.org/blog/date/2006/09/>
- August 2006 <http://www.webkit.org/blog/date/2006/08/>
- June 2006 <http://www.webkit.org/blog/date/2006/06/>
- May 2006 <http://www.webkit.org/blog/date/2006/05/>
- April 2006 <http://www.webkit.org/blog/date/2006/04/>
- March 2006 <http://www.webkit.org/blog/date/2006/03/>
- February 2006 <http://www.webkit.org/blog/date/2006/02/>
- January 2006 <http://www.webkit.org/blog/date/2006/01/>
- December 2005 <http://www.webkit.org/blog/date/2005/12/>
- November 2005 <http://www.webkit.org/blog/date/2005/11/>
- October 2005 <http://www.webkit.org/blog/date/2005/10/>
- September 2005 <http://www.webkit.org/blog/date/2005/09/>
- August 2005 <http://www.webkit.org/blog/date/2005/08/>
- July 2005 <http://www.webkit.org/blog/date/2005/07/>
- June 2005 <http://www.webkit.org/blog/date/2005/06/>
WebKit is open source software with portions licensed under the
LGPL<http://www.webkit.org/coding/lgpl-license.html>
and BSD licenses <http://www.webkit.org/coding/bsd-license.html>. Complete
license and copyright information can be found within the code.
Hosting provided by Mac OS Forge <http://www.macosforge.org/>. Use of this
site is subject to the Mac OS Forge Terms of
Use<http://www.macosforge.org/terms/>
.
Surfin' Safari site is powered by WordPress <http://wordpress.org/>
Entries (RSS) <http://www.webkit.org/blog/feed/> and Comments
(RSS)<http://www.webkit.org/blog/comments/feed/>
.
Site Admin <http://www.webkit.org/blog/wp-admin/> *|* Log
out<http://www.webkit.org/blog/wp-login.php?action=logout&_wpnonce=a29ef5c576>
On Fri, Apr 29, 2011 at 11:09 PM, David Kilzer <ddkilzer at webkit.org> wrote:
> Hi Pavel,
>
> You need to send the contents of the blog post via email. Not everyone can
> read it (even after logging in).
>
> Dave
>
>
> On Apr 29, 2011, at 11:44 AM, Pavel Feldman wrote:
>
> Hi guys,
>
> I started drafting the blog post "Remote Debugging with Web Inspector":
> http://www.webkit.org/blog/?p=1620&preview=true.
>
> I'd like to cover following topics there:
>
> - ability to use Web Inspector front-end with remote / embedded devices
> - ability to implement alternate front-ends for IDEs
> - share the update on the protocol work progress
>
> Calling for the early feedback.
>
> Thanks
> Pavel
>
> On Mon, Aug 9, 2010 at 11:48 PM, Pavel Feldman <pfeldman at chromium.org>wrote:
>
>> Hi guys,
>>
>> As some of you know, we are working on a remote debugging feature in Web
>> Inspector. There are many good reasons behind the project including the
>> following:
>>
>> - Debugging WebKit on embedded devices
>> - Shaping up a good protocol for ourselves
>> - Introducing external SDKs on top of the protocol for IDE integrations
>> and alternate front-ends
>>
>> We've had serialized interaction with the out-of-process inspector for
>> quite a while in Chromium. We were upstreaming it into WebKit and have
>> reached an important milestone recently: all the interaction between the
>> inspected page and inspector is entirely serialized on the WebKit level. All
>> the embedder needs to do is to implement a socket that would serve the
>> inspector front-end files and provide our messaging with appropriate
>> transport.
>>
>> Now this socket is likely to be platform-specific, implemented on the
>> WebKit and/or host browser levels. It also makes more sense to implement
>> socket on mobile platforms first. However, we've done a proof-of-concept
>> implementation in Chromium and it is now in a demoable state! See the
>> screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium
>> nightly to the left + WebKit nightly to the right. WebKit nightly connects
>> remotely to Chromium over HTTP on the port 9222 and does remote debugging
>> including DOM inspection, breakpoints and such. The communication is
>> established by means of a WebSocket. The interesting thing about the
>> implementation is that inspector front-end is fetched from the host browser,
>> so that there is no mess with protocol versioning and no need in exposing
>> the interaction protocol any time soon.
>>
>> So I made the demo and it looked cool. I thought maybe we do a blog post
>> on it. The blog post would draw attention to the Web Inspector and its
>> progress, share the remote debugging vision with the interested parties and
>> would simply look cool. Front-end is working as a pure HTML5 application
>> (obviously full of WebKit-specific styles, but still) which is impressive.
>> Now the project is nowhere complete in terms of finalizing the message
>> format and the protocol itself, but there is no intention to expose it right
>> now. We'd like to let it live with fetchable front-end and mature before we
>> expose the protocol and commit to any level of interface support.
>>
>> What do you think, is it ready for a blog post?
>>
>> Thanks
>> Pavel
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110430/ff9e7239/attachment.html>
More information about the webkit-dev
mailing list