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 > 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. > > > 4. Follow any of these links to start remote debugging session for the > corresponding 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 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. For your convenience, we > generated documentation from this schema and published it on the Chrome > DevTools page. 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 and the Chrome > DevTools forum 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
