My favorites | Sign in
Google
Project hosting will be READ-ONLY Wednesday at 8am PST due to brief network maintenance.
                
Search
for
Updated Aug 10, 2009 by apavlov@chromium.org
ChromeDevToolsProtocol  
Google Chrome Developer Tools Protocol

Introduction

The existing V8 Debugger Protocol is not sufficient to provide Google Chrome, Chromium, or any other browser that supports the protocol, with the capability of remote debugging via TCP/IP sockets. The V8 Debugger protocol covers only JavaScript debugging operations, and only within a single V8 virtual machine (VM). In reality, there can be one or more separate V8 VMs inside a Google Chrome instance, residing in different renderer processes. Also, retrieving URLs loaded in the browser tabs, inspecting or modifying the DOM tree are not covered by JavaScript operations.

Because of these restrictions, the ChromeDevTools protocol has been created to enable the exchange of additional information between a remote debugger and the browser instance being debugged. The ChromeDevTools protocol can be used as a transport for other debugging-related protocols, including the existing V8 Debugger Protocol. The proposed protocol can be used as a transport for other debugging-related protocols, including the existing V8 Debugger Protocol.

A single subsystem that uses ChromeDevTools protocol as a transport for its own debugging-related protocol is called a "Tool". A V8 VM Debugger, a DOM debugger, or a Developer Tools Service are examples of a Tool.

Protocol Message Structure

For simplicity of parsing, and higher human readability, the generic protocol message structure follows that of an HTTP request/response message (barring the Starting line):

Header1
...
HeaderN
<empty line>
Content

where <empty line> represents a single pair of the \r\n (CR LF) characters.

A single header format is:

<HeaderName>:<HeaderValue>CRLF

Request/Response message headers

Content-Length (required) - the total length of the Сontent field in bytes.

Tool (required) - a string specifying the Tool that will handle the message.

Destination (optional) - a string that identifies the concrete application-specific host object in whose context the message should be handled. For a V8 debugger it can be an identifier of a Google Chrome tab running JavaScript code, and for Developer Tools Service it can be absent altogether because the content pertains to the global Google Chrome context rather than some specific object contained in the browser (e.g. the content can contain a request for the supported version of the Developer Tools protocol.) "0" (zero) is an invalid host object identifier, reserved for specific protocol purposes.

Note: Tools may add other headers that they will extract while processing messages.

Content

The optional Content field value is unique to each command as well as the request/response message. For example, it can contain the V8 Debugger Protocol request/response JSON messages or some plain-text command for a simpler tool. The content must use the UTF8 charset. If this field is absent, the Content-Length header value must be 0.

Establishing the Debugger Connection

A remote debugger that supports the ChromeDevTools protocol, connects to a server socket opened by Google Chrome. A remote debugger sends a handshake message consisting of 23 ASCII characters,

ChromeDevToolsHandshakeCRLF

Google Chrome replies with the same 23-byte message.

Once the connection is established, the remote debugger might want to query the list of tabs using the list_tabs command.

Supported Tools

Currently, all the supported Tools use JSON as the Content format.

DevToolsService

This tool provides a remote debugger with information about the inspectable environment.

Common DevToolsService JSON fields:

Available commands:

The following result codes are possible:

The request/response examples:

Command Request content Response "data" field
ping {"command":"ping"} {"command":"ping", "result":0, "data":"ok"}
version {"command":"version"} {"command":"version", "result":0, "data":version_id}
list_tabs {"command":"list_tabs"} {"command":"list_tabs", "result":0, "data":[[tab1_id,"tab1_url"], [tab2_id,"tab2_url"]]}

V8Debugger

This tool enables communication between a remote debugger and the V8 debuggers running inside a Google Chrome instance.

Common V8Debugger JSON fields:

Available commands:

The following result codes are possible:

The request/response examples:

Command Request Data Response Data
attach
  • Destination: tab_id
  • Content: {"command":"attach"}
  • Destination: tab_id
  • Content: {"command":"attach", "result":result_code}
detach
  • Destination: tab_id
  • Content: {"command":"detach"}
  • Destination: tab_id
  • Content: {"command":"detach", "result":result_code}
debugger_command
  • Destination: tab_id
  • Content: {"command":"debugger_command", "data":debugger_json}
  • Destination: tab_id
  • Content: {"command":"debugger_command", "result":result_code, "data":debugger_response_json}
evaluate_javascript
  • Destination: tab_id
  • Content: {"command":"evaluate_javascript", "data":"some_javascript"}
none
navigated none (event)
  • Destination: tab_id
  • Content: {"command":"navigated", "result":0, "data":"new_url"}
closed none (event)
  • Destination: tab_id
  • Content: {"command":"closed", "result":0}


Comment by szegedia, Aug 05, 2009

Looking at the source code of org.chromium.sdk.internal.transport.Message, Content-Length actually expresses the number of characters in the content, not the number of bytes.

I'm actually okay with that as it allows me to read all messages using a single reader and don't have to juggle a Reader and an InputStream?, but you should fix the docs.

Comment by szegedia, Aug 05, 2009

Errata: response for "list_tabs" has wrong "command".

Comment by szegedia, Aug 05, 2009

Your implementation of "backtrace" command uses a boolean argument named "inlineRefs", but it's not documented in the V8 protocol.

Comment by szegedia, Aug 06, 2009

What's the response if the debugged target (i.e. Chromium) doesn't recognize the value of the Tool header?

Comment by alexandre.nascimento, Oct 02, 2009

{"command":"ping", "result":0, "data":"ok"}

Comment by rolyv19, Nov 18, 2009

I'm sending an "evaluate_javascript" command getting back a "debugger_command" response??!? any thoughts?

Comment by szegedia, Jan 10, 2010

rolyv19: yup, it's compiling that "javascript:void(0);" from "evaluate_javascript" and sending you back an "afterCompile" event about it.


Sign in to add a comment