devtools-docs/docs/debugger-protocol.html

{{+bindTo:partials.standard_devtools_article}}
<h1>Remote debugging protocol</h1>





<p>Under the hood, Chrome Developer Tools is a web application written in HTML,
JavaScript and CSS. It has a special binding available at JavaScript runtime
that allows interacting with chrome pages and instrumenting them. Interaction
protocol consists of commands that are sent to the page and events that
the page is generating. Although Chrome Developer Tools is the only client of
this protocol, there are ways for third parties to bypass it and start
instrumenting browser pages explicitly. We will describe the ways it could be
done below.</p>

<p class="note"><b>Note:</b> If you are interested in inspecting remote pages on Chrome for Android, please see the <a href="remote-debugging.html">remote debugging documentation</a>. For users wishing to implement custom inspection code using our debugger protocol instead, please use the instructions below.</p>

<div class="collapsible">
<h2 id="protocol">Protocol</h2>
<p>Interaction protocol consists of JSON commands that are sent to the page and
events that the page is generating. We define this protocol in Blink
("upstream") so that any Blink-based browser supported it.</p>

<p>
  <ul>
<li>As of Google Chrome M31, we commit to supporting the version
<a href="protocol/1.1/index.html">1.1</a> of the protocol. All
subsequent 1.* versions of the protocol are going to be backwards compatible with 1.1.</li>
  <li>As of Google Chrome M18, we commit to supporting the version
<a href="protocol/1.0/index.html">1.0</a> of the protocol. All
subsequent 1.* versions of the protocol are going to be backwards compatible with 1.0.</li>
  <li>As of Google Chrome M16, we commit to supporting the version
<a href="protocol/0.1/index.html">0.1</a> of the protocol. All
subsequent 0.* versions of the protocol are going to be backwards compatible with 0.1.</li>
</li>
</ul>

</p>
<p>
Protocol backwards compatibility is defined as follows:
  <ul>
<li>No commands or events are removed from the protocol</li>
  <li>No required parameters are added to the commands</li>
  <li>No required parameters are removed from command responses or events</li>
</ul>
</p>

<p>There also is a <a href="protocol/tot/index.html">tip-of-tree</a> version of the
protocol that reflects present state of the protocol in Blink repository. You can
use it with <a href="http://tools.google.com/dlpage/chromesxs">Google Canary</a>
builds at your own risk. Note that unless tip of the tree revision is promoted to the
draft, there is no backwards compatibility support guaranteed for the capabilities it
introduces.</p>


<p>DevTools may introduce new features that are not currently documented under the tip-of-tree protocol documentation. You can discover these if you want to try using features, however, the undocumented protocol is volatile and may break at any time. First, <a href="https://developers.google.com/chrome-developer-tools/docs/contributing#step_3_inspector_inception">inspect the inspector</a> and reload the inspector so your attached one can view its WebSocket connection (<code>Network > Filter > WebSockets</code>). Then view the frames of WebSocket activity as you use the host DevTools. You may need to re-click the WebSocket item to have the Frame activity update.</p>

<figure class="screenshot"> <a href="debugger-protocol/debugger-protocol-sniffing-full.jpg"><img src="debugger-protocol/debugger-protocol-sniffing.jpg" alt="Sniffing the debugger protocol" /></a></figure>

<h2 id="remote">Debugging over the wire</h2>
<p>Today Developer Tools front-end can attach to a remotely running Chrome
instance for debugging.

For this scenario to work, you should start your
<i>host</i> Chrome instance with the remote-debugging-port
command line switch:</p>

<div class="summary">
chrome.exe --remote-debugging-port=9222
</div>

<p>Then you can start a <i>client</i> Chrome instance, using a separate user profile:</p>

<div class="summary">
chrome.exe --user-data-dir=&lt;some directory&gt;
</div>

<p>And now you can navigate to the given port from your <i>client</i> and attach to
any of the discovered tabs for debugging.</p>

<div class="summary">
http://localhost:9222
</div>

<p>You will find Developer Tools interface identical to the embedded one and
here is why:</p>
<ul>
<li>When you navigate your <i>client</i> browser to the remote's Chrome port,
Developer Tools front-end is being served from the <i>host</i> Chrome
as a Web Application from the Web Server.</li>
<li>It fetches HTML, JavaScript and CSS files over HTTP</li>
<li>Once loaded, Developer Tools establishes a Web Socket connection to its
host and starts interchanging JSON messages with it.
</li>
</ul>

<p>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 issuing the following HTTP request to the browser:</p>

<div class="summary">
http://localhost:9222/json
</div>

<p>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.</p>
<p class="note">Note that we are currently working on exposing an HTTP-based
protocol that does not require client WebSocket implementation.</p>

<p>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.</p>

</div>
<div class="collapsible">
<h2 id="extension">Using debugger extension API</h2>
<p>To allow third parties to interact with the protocol, we introduced
<a href="https://developer.chrome.com/extensions/debugger.html">
chrome.debugger</a> 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.</p>

<p>Chrome Debugger Extension API provides a higher level API where command
domain, name and body are provided explicitly in the <code>sendCommand</code>
call. This API hides request ids and handles binding of the request with its
response, hence allowing <code>sendCommand</code> to report result in the
callback function call. One can also use this API in combination with the other
Extension APIs.
</p>

<p>If you are developing a Web-based IDE, you should implement an extension that
exposes debugging capabilities to your page and your IDE will be able to open
pages with the target application, set breakpoints there, evaluate expressions
in console, live edit JavaScript and CSS, display live DOM, network interaction
and any other aspect that Developer Tools is instrumenting today.</p>

<p class="note">Note: opening embedded Developer Tools will terminate the
remote connection / detach the extension and will replace active debugger with
itself. We are working on allowing several clients to instrument the page
simultaneously.</p>
<p></p>




</div>
{{/partials.standard_devtools_article}}