This is really about the Web Inspector + about the new protocol that is a part of Web Inspector. The whole point of the post is that the same protocol is used for any WebKit-based product.
Chrome is there as a proof of concept demo only. We need some shiny demo material for post so that people could see it and try it themselves. Otherwise, it becomes a boring chunk of text. I could use screenshots with Playbook's capabilities ( http://www.berryreview.com/2011/04/15/hot-webkit-web-inspector-on-the-blackberry-playbook-for-web-developers/) or both Chrome and Playbook. Any RIM people around? Thanks Pavel On Sat, Apr 30, 2011 at 2:23 PM, Mark Rowe <mr...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev