<div><meta charset="utf-8"><div>I see. It might be unfortunate branding, but the large amount of Web Inspector users refer to it as "Developer Tools". We use every opportunity to tell users that it is the same thing, but this is not enough. The first question we always get is "Do you guys upstream any of your Chrome Dev Tools code into the WebKit?". Which sounds crazy, because 100% of the code is upstream. So it is probably just me trying to use both names to fix this. It sounds like I should be more formal in this case and make the letter of the post conform to its WebKit spirit.</div>
</div><div><br></div>- I changed the phrasing to use "Web Inspector" only, there is no mention of "Chrome Dev Tools" anymore.<div>- Removed all "Chrome" mentions as well</div><div>- There is now single mention of "Chromium" in the example scenario that I am eager to keep. I truly believe that the example makes the post more lively. There is nothing easier than posting this whole thing at <a href="http://chromium.org">chromium.org</a>, but it will harm the "unified WebKit Remote Debugging Protocol" message we are trying to deliver.</div>
<div><br></div><div><provocative>In return, can I ask to rename the WebKit blog from "Surfin' Safari" to something more WebKit-specific?</provocative></div><div><br></div><div>So here is another update (posting the first topics that have changed). Mark, Evan, do you think it is better now?</div>
<div><br></div><div><meta charset="utf-8"><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: 'Lucida Grande', Verdana, Arial; font-size: 12px; line-height: 18px; "><h2 style="margin-bottom: 0px; text-shadow: rgb(187, 187, 187) 1px 1px 1px; font-size: 16px; color: rgb(0, 51, 0) !important; ">
<a href="http://www.webkit.org/blog/?p=1620" rel="bookmark" title="Permanent Link: WebKit Remote Debugging" style="text-decoration: none; color: rgb(34, 136, 17) !important; ">WebKit Remote Debugging</a></h2><small style="color: rgb(119, 119, 119); ">Posted by <strong>Pavel Feldman</strong> on Saturday, April 30th, 2011 at 10:06 pm</small><div class="entrytext">
<p style="min-width: 400px; ">As you might know, WebKit Web Inspector 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.</p>
<h3 style="margin-bottom: 0px; text-shadow: rgb(187, 187, 187) 1px 1px 1px; font-size: 14px; color: rgb(0, 51, 0) !important; ">Debugging over the wire</h3><p style="min-width: 400px; margin-top: 2px; "></p><p style="min-width: 400px; ">
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 Chromium:</p>
<p style="min-width: 400px; ">1. Start your target browser with the remote-debugging-port command line switch:</p><p style="min-width: 400px; "><code style="font-family: Courier, Fixed; font-size: 13px; ">Chromium --remote-debugging-port=9222</code></p>
<p style="min-width: 400px; ">2. Open several pages there.</p><p style="min-width: 400px; ">3. Navigate to the given port from your client browser instance (WebKit nightly will do) and it will list inspectable pages opened in the browser as web links.<br>
<img src="http://www.webkit.org/blog-files/inspector/remote-debugging-discovery.png" alt="Tab discovery page" style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; max-width: 100%; margin-bottom: -20px; "></p>
<p style="min-width: 400px; ">4. Follow any of these links to start remote debugging session for the corresponding page.<br><img src="http://www.webkit.org/blog-files/inspector/remote-debugging-attached.png" alt="Tab attached page" style="padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; max-width: 100%; margin-bottom: -20px; "></p>
<p style="min-width: 400px; ">You will find remote debugging interface very similar to the Web Inspector and here is why:</p><ul style="margin-top: 4px; margin-right: 0px; margin-bottom: 4px; margin-left: 0px; "><li style="margin-top: 4px; margin-right: 0px; margin-bottom: 4px; margin-left: 0px; list-style-image: url(http://www.webkit.org/images/green-bullet.png) !important; ">
Target browser acts as a web server bound to the port 9222 on the localhost.</li><li style="margin-top: 4px; margin-right: 0px; margin-bottom: 4px; margin-left: 0px; list-style-image: url(http://www.webkit.org/images/green-bullet.png) !important; ">
Once you follow the link, your client browser fetches HTML, JavaScript and CSS files of the Web Inspector front-end over HTTP.</li><li style="margin-top: 4px; margin-right: 0px; margin-bottom: 4px; margin-left: 0px; list-style-image: url(http://www.webkit.org/images/green-bullet.png) !important; ">
Upon load event, Web Inspector establishes Web Socket connection back to the target browser and starts interchanging JSON messages with it.</li></ul><p style="min-width: 400px; ">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.</p>
</div></span></div><div><br></div><div><div class="gmail_quote">On Sun, May 1, 2011 at 1:32 AM, Evan Martin <span dir="ltr"><<a href="mailto:evan@chromium.org">evan@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<div>

<br></div><div>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.<div><div></div><div class="h5"><br><br><div class="gmail_quote">
On Sat, Apr 30, 2011 at 3:23 AM, Mark Rowe <span dir="ltr"><<a href="mailto:mrowe@apple.com" target="_blank">mrowe@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This seems rather Chrome-centric for a <a href="http://webkit.org" target="_blank">webkit.org</a> blog post.<div>

<br></div><div>- Mark</div><div><br><div><div><div></div><div><div>On 2011-04-30, at 01:55, Pavel Feldman wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div>An update.<div><br></div>
<div>Pavel<br><div><br></div><div><span style="border-collapse:collapse;color:rgb(51, 51, 51);font-family:'Lucida Grande', Verdana, Arial;font-size:12px;line-height:18px"><div>
<h2 style="margin-bottom:0px;text-shadow:rgb(187, 187, 187) 1px 1px 1px;font-size:16px;color:rgb(0, 51, 0) !important"><a href="http://www.webkit.org/blog/?p=1620" rel="bookmark" title="Permanent Link: WebKit Remote Debugging" style="color:rgb(34, 136, 17) !important;text-decoration:none" target="_blank">WebKit Remote Debugging</a></h2>


<small style="color:rgb(119, 119, 119)">Posted by <strong>Pavel Feldman</strong> on Saturday, April 30th, 2011 at 1:53 am</small><div><div style="color:rgb(80, 0, 80)"><p style="min-width:400px">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.</p>


</div><h3 style="margin-bottom:0px;text-shadow:rgb(187, 187, 187) 1px 1px 1px;font-size:14px;color:rgb(0, 51, 0) !important">Debugging over the wire</h3><div style="min-width:400px;margin-top:2px"><br></div><p style="min-width:400px">


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:</p>


<div style="color:rgb(80, 0, 80)"><p style="min-width:400px">1. Start your target browser (recent Chromium build or Google Chrome will do) with the remote-debugging-port command line switch:</p><p style="min-width:400px">


<code style="font-family:Courier, Fixed;font-size:13px">Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222</code></p></div><p style="min-width:400px">2. Open several pages there.</p><p style="min-width:400px">


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.<br><img alt="Tab discovery page" style="padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-width:100%"></p>

<p style="min-width:400px">4. Follow any of these links to start remote debugging session for the corresponding page.<br><img alt="Tab attached page" style="padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;max-width:100%"></p>


<div style="color:rgb(80, 0, 80)"><p style="min-width:400px">You will find remote debugging interface very similar to the Web Inspector / Chrome Developer Tools and here is why:</p><ul style="margin-top:4px;margin-right:0px;margin-bottom:4px;margin-left:0px">


<li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">Target Chrome browser acts as a web server bound to the port 9222 on the localhost.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">


Once you follow the link, your client browser fetches HTML, JavaScript and CSS files of the Developer Tools front-end over HTTP.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">Upon load event, Developer Tools establishes Web Socket connection back to the target browser and starts interchanging JSON messages with it.</li>


</ul><p style="min-width:400px">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.</p>


<h3 style="margin-bottom:0px;text-shadow:rgb(187, 187, 187) 1px 1px 1px;font-size:14px;color:rgb(0, 51, 0) !important">Remote Debugging Protocol</h3><div style="min-width:400px;margin-top:2px"><br></div></div><p style="min-width:400px">


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.</p>

<p style="min-width:400px">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 <a href="http://groups.google.com/group/json-rpc/web/json-rpc-2-0" style="color:rgb(34, 136, 17) !important;text-decoration:none" target="_blank">JSON-RPC 2.0</a> 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:</p>


<div style="color:rgb(80, 0, 80)"><ul style="margin-top:4px;margin-right:0px;margin-bottom:4px;margin-left:0px"><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">
<b>Browser Debugger</b> – allows setting breakpoints on particular DOM operations and events. JavaScript execution will stop on these operations as if there was a regular breakpoint set.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">


<b>Console</b> – defines methods and events for interaction with the JavaScript console.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px"><b>CSS</b> – exposes raw CSS read / write operations.</li>


<li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px"><b>Debugger</b> – exposes JavaScript debugging functions; allows setting and removing breakpoints, stepping through execution, exploring stack traces, etc.</li>


<li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px"><b>DOM</b> – This domain exposes DOM read/write operations.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">


<b>Network</b> – allows tracking network activities of the page; exposes information about HTTP and WebSocket requests and responses, their headers, bodies, raw timing, etc.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px">


<b>Page</b> – actions and events related to the inspected page.</li><li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px"><b>Runtime</b> – exposes JavaScript runtime by means of remote evaluation and mirror objects.</li>


<li style="margin-left:0px;margin-top:4px;margin-right:0px;margin-bottom:4px"><b>Timeline</b> – provides its clients with instrumentation records that are generated during the page runtime.</li></ul><p style="min-width:400px">


You can find JSON schema defining the protocol <a href="http://trac.webkit.org/browser/trunk/Source/WebCore/inspector/Inspector.json" style="color:rgb(34, 136, 17) !important;text-decoration:none" target="_blank">here</a>. For your convenience, we generated documentation from this schema and published it on the <a href="http://code.google.com/chrome/devtools/docs/remote-debugging.html" style="color:rgb(34, 136, 17) !important;text-decoration:none" target="_blank">Chrome DevTools page</a>. 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.</p>


<h3 style="margin-bottom:0px;text-shadow:rgb(187, 187, 187) 1px 1px 1px;font-size:14px;color:rgb(0, 51, 0) !important">What’s next</h3><div style="min-width:400px;margin-top:2px"><br></div></div><p style="min-width:400px">


We are now open to the feedback on the WebKit Remote Debugging Protocol. We will collect all the feedback in the form of the <a href="http://webkit.org/new-inspector-bug" style="color:rgb(34, 136, 17) !important;text-decoration:none" target="_blank">bug reports</a> and the Chrome DevTools <a href="http://groups.google.com/group/google-chrome-developer-tools" style="color:rgb(34, 136, 17) !important;text-decoration:none" target="_blank">forum</a> 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!</p>


<div><div><span style="color:rgb(80, 0, 80);font-size:9px">- Show quoted text -</span></div></div></div></div><div style="min-width:400px;color:rgb(119, 119, 119);text-align:center;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px">


Comments are closed.</div></span></div></div></div></div><div>
_______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br><a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>

</div></blockquote></div><br></div></div><br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div>