The Chrome DevTools Protocol allows for tools to instrument, inspect, debug and profile Chromium, Chrome and other Blink-based browsers. Many existing projects currently use the protocol. The Chrome DevTools uses this protocol and the team maintains its API.
Protocol API Docs
It changes frequently and can break at any time. However it captures the full capabilities of the Protocol, whereas the stable release is a subset. There is no backwards compatibility support guaranteed for the capabilities it introduces.
The stable release of the protocol, tagged at Chrome 54. It includes a smaller subset of the complete protocol compatibilities.
Consider subscribing to the chrome-debugging-protocol mailing list.
The devtools-protocol repo issue tracker can also be used for concerns with the protocol. It also hosts the canonical copy of the json files.
Basics: Using DevTools as protocol client
The Developer Tools front-end can attach to a remotely running Chrome instance for debugging. For this scenario to work, you should start your host Chrome instance with the remote-debugging-port command line switch:
Then you can start a separate client Chrome instance, using a distinct user profile:
chrome.exe --user-data-dir=<some directory>
Now you can navigate to the given port from your client and attach to any of the discovered tabs for debugging: http://localhost:9222
You will find the Developer Tools interface identical to the embedded one and here is why:
- When you navigate your client browser to the remote's Chrome port, Developer Tools front-end is being served from the host Chrome as a Web Application from the Web Server.
- Once loaded, Developer Tools establishes a Web Socket connection to its host and starts exchanging JSON messages with it.
In this scenario, you can substitute Developer Tools front-end with your own implementation. Instead of navigating to the HTML page at http://localhost:9222, your application can discover available pages by requesting: http://localhost:9222/json and getting a JSON object with information about inspectable pages along with the WebSocket addresses that you could use in order to start instrumenting them.
Remote debugging is especially useful when debugging remote instances of the browser or attaching to the embedded devices. Blink port owners are responsible for exposing debugging connections to the external users.
If you need the protocol version for a specific Chrome client, glance at
fetchFromChromeRepo from chrome-remote-interface's
Sniffing the protocol
This is especially handy to understand how the DevTools frontend makes use of the protocol. First, run Chrome with the debugging port open:
alias canary="/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary" canary --remote-debugging-port=9222 http://localhost:9222 http://chromium.orgThen, select the Chromium Projects item in the Inspectable Pages list. Now that DevTools is up and fullscreen, open DevTools to inspect it. Cmd-R in the new inspector to make the first restart. Now head to Network Panel, filter by Websocket, select the connection and click the Frames tab. Now you can easily see the frames of WebSocket activity as you use the first instance of the DevTools.
DevTools protocol via Chrome extension
To allow chrome extensions to interact with the protocol, we introduced chrome.debugger extension API that exposes this JSON message transport interface. As a result, you can not only attach to the remotely running Chrome instance, but also instrument it from its own extension.
Chrome Debugger Extension API provides a higher level API where command
domain, name and body are provided explicitly in the
call. This API hides request ids and handles binding of the request with its
response, hence allowing
sendCommand to report result in the
callback function call. One can also use this API in combination with the other
Opening embedded Developer Tools will terminate the remote connection and thus detach the extension.
Simultaneous protocol clients
We currently do not support multiple clients connected to the protocol simultaneously. This includes opening DevTools while another client is connected. On the bug tracker, crbug.com/129539 follows the issue; you can star it for email updates.
Upon disconnnection, the outgoing client will receive a
View the enum of
(For reference: the original patch).
After disconnection, some apps have chosen to pause their state and offer a reconnect button.