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

[Evan Martin]

I think Mark's point was more about phrasing like "WebKit Web Inspector (aka
Chrome Developer Tools)" or "You will find remote debugging interface very
similar to the Web Inspector / Chrome Developer Tools and here is
why: Target Chrome browser acts as".  I think that objection is reasonable.

Perhaps you could rearrange the post to be solely about the WebKit-specific
parts, and include a link to a Chrome blog post with details for Chrome
users.

On Sat, Apr 30, 2011 at 3:23 AM, Mark Rowe <mrowe at apple.com> wrote:

> This seems rather Chrome-centric for a webkit.org blog post.
>
> - Mark
>
> On 2011-04-30, at 01:55, Pavel Feldman wrote:
>
> 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.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> 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/4aea92de/attachment.html>