|
ChromeDevToolsProtocol
Google Chrome Developer Tools Protocol
IntroductionThe 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 StructureFor 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 ConnectionA 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 ToolsCurrently, all the supported Tools use JSON as the Content format. DevToolsServiceThis 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:
V8DebuggerThis 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:
|
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.
Errata: response for "list_tabs" has wrong "command".
Your implementation of "backtrace" command uses a boolean argument named "inlineRefs", but it's not documented in the V8 protocol.
What's the response if the debugged target (i.e. Chromium) doesn't recognize the value of the Tool header?
{"command":"ping", "result":0, "data":"ok"}
I'm sending an "evaluate_javascript" command getting back a "debugger_command" response??!? any thoughts?
rolyv19: yup, it's compiling that "javascript:void(0);" from "evaluate_javascript" and sending you back an "afterCompile" event about it.