Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
CC'ed Konrad, who is one of the web inspector developers/porters on the Playbook side. On Sat, Apr 30, 2011 at 6:42 AM, Pavel Feldman pfeld...@chromium.orgwrote: 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? -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Hi! On Apr 30, 2011, at 10:11 PM, Pavel Feldman pfeld...@chromium.org wrote: provocativeIn return, can I ask to rename the WebKit blog from Surfin' Safari to something more WebKit-specific?/provocative Well, that would just be ridiculous, because the Beach Boys reference is awesome! Sent from my iPhone ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
An update. Pavel WebKit Remote Debugging http://www.webkit.org/blog/?p=1620Posted 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 herehttp://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 pagehttp://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
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
On 04/30/2011 10:55 AM, Pavel Feldman wrote: An update. Did you consider applying for a port number at IANA? Besides that really nice work and a nice article. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
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
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
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
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
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 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
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
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. - I changed the phrasing to use Web Inspector only, there is no mention of Chrome Dev Tools anymore. - Removed all Chrome mentions as well - 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 chromium.org, but it will harm the unified WebKit Remote Debugging Protocol message we are trying to deliver. provocativeIn return, can I ask to rename the WebKit blog from Surfin' Safari to something more WebKit-specific?/provocative So here is another update (posting the first topics that have changed). Mark, Evan, do you think it is better now? WebKit Remote Debugging http://www.webkit.org/blog/?p=1620Posted by *Pavel Feldman* on Saturday, April 30th, 2011 at 10:06 pm 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. 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 Chromium: 1. Start your target browser with the remote-debugging-port command line switch: Chromium --remote-debugging-port=9222 2. Open several pages there. 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. [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 and here is why: - Target 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 Web Inspector front-end over HTTP. - Upon load event, Web Inspector 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. On Sun, May 1, 2011 at 1:32 AM, Evan Martin e...@chromium.org wrote: 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 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
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
On 2011-04-30, at 22:11, Pavel Feldman wrote: 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. - I changed the phrasing to use Web Inspector only, there is no mention of Chrome Dev Tools anymore. - Removed all Chrome mentions as well - 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 chromium.org, but it will harm the unified WebKit Remote Debugging Protocol message we are trying to deliver. provocativeIn return, can I ask to rename the WebKit blog from Surfin' Safari to something more WebKit-specific?/provocative I've wondered the same thing myself on several occasions. So here is another update (posting the first topics that have changed). Mark, Evan, do you think it is better now? The update certainly addresses my concerns. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Hi guys, I started drafting the blog post Remote Debugging with Web Inspector: http://www.webkit.org/blog/?p=1620preview=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 pfeld...@chromium.orgwrote: 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
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=1620preview=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 pfeld...@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@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
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Surfin' Safari Web Inspector: Understanding Stack Traceshttp://www.webkit.org/blog/1544/web-inspector-understanding-stack-traces/ Remote Debugging with Web Inspector http://www.webkit.org/blog/?p=1620Posted 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 herehttp://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 pagehttp://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 reportshttp://webkit.org/new-inspector-bug and the Chrome DevTools
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
On Aug 9, 2010, at 3:48 PM, ext Pavel Feldman 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? I think it is ready for a blog post. Nice work! I've been leveraging your work to make remote Web Inspector work in QtWebKit. I've also been working on exposing a ChromeDevTools / V8 debugger protocol backend so that we can use an Eclipse IDE for W3C Widget and Qt WRT debugging. The IDE debugger backend is structured as an alternate front-end for Web Inspector. I submitted several patches to enable that, and I think our debugger backend is getting to a state where I'm willing to post that code as well. Best regards, Jamey Hicks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
On Aug 9, 2010, at 12:48 PM, Pavel Feldman wrote: 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. Great demo! [...] 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. [...] What do you think, is it ready for a blog post? The concern I had was that this isn't readily available in the browser for download on webkit.org (WebKit nightly). In that way, I think for many it will feel a bit like a teaser. However, WebKit is an open source project, so I'd expect to see all kinds of WebKit related news and blog posts available there. In the end I feel the more publicity the better. Especially when someone just expressed an interest in seeing more interesting blog posts. The last blog post on the Web Inspector was in April. Before that it was November. That was a 5 month spread, and this would be a 4 month spread. Thats a pretty consistent rate showing off awesome work. - Joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
I would be interested as well in seeing a blog post about this new feature. Very cool stuff, good work! Josh ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
