190 строки
9.0 KiB
HTML
190 строки
9.0 KiB
HTML
{{+bindTo:partials.standard_devtools_article}}
|
|
<h1>Chrome 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. The interaction
|
|
protocol consists of commands that are sent to the page, and events that
|
|
the page is generating. Although Chrome Developer Tools is the primary client of
|
|
this protocol, including for <a href="remote-debugging.html">remote debugging</a>, there are ways for third parties to use it and start
|
|
instrumenting browser pages explicitly.
|
|
</p>
|
|
|
|
<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 so that any Blink-based browser can support it.
|
|
</p>
|
|
|
|
|
|
<div class="collapsible">
|
|
<h2 id="protocol">Latest Protocol</h2>
|
|
|
|
<p>
|
|
The <a href="https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/protocol.json&q=protocol.json&sq=package:chromium&type=cs">tip-of-tree protocol</a>
|
|
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. You can
|
|
use it with <a href="http://tools.google.com/dlpage/chromesxs">Chrome Canary</a>
|
|
builds or tip of tree Chromium. See the <em>Sniffing the protocol</em> section below to identify the protocol commands used by Chrome.
|
|
|
|
|
|
<p> The tip-of-tree protocol <a href="https://chromium.googlesource.com/chromium/src/third_party/WebKit/Source/devtools/+/master/protocol.json">changes frequently</a>. If you need the protocol version for a specific Chrome client, this <a href="https://github.com/cyrus-and/chrome-remote-interface/issues/10#issuecomment-146032907
|
|
">snippet will provide the protocol JSON</a> based on the client's <code>/json/version</code>.
|
|
|
|
<h3>Debugging Protocol Viewer</h3>
|
|
<center><a href="https://chromedevtools.github.io/debugger-protocol-viewer/"><img src="../images/protocol-viewer.png" height="327" width="500"></a></center>
|
|
<p>
|
|
The <a href="https://chromedevtools.github.io/debugger-protocol-viewer/">Chrome debugger protocol viewer</a> offers a more readable view of the tip-of-tree protocol.
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="collapsible">
|
|
<h3 id="protocol">Frozen 1.2 Protocol</h3>
|
|
|
|
<p>
|
|
<a href="https://chromedevtools.github.io/debugger-protocol-viewer/1-2/">Debugger protocol version 1.2</a> is the latest stable release of the protocol,
|
|
tagged at Chrome 54.
|
|
</p>
|
|
|
|
</div>
|
|
|
|
<div class="collapsible">
|
|
<h2 id="remote">Debugging over the wire</h2>
|
|
<p>The 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>
|
|
|
|
<pre class="summary">
|
|
chrome.exe --remote-debugging-port=9222</pre>
|
|
|
|
<p>Then you can start a separate <i>client</i> Chrome instance, using a distinct user profile:</p>
|
|
|
|
<pre class="summary">
|
|
chrome.exe --user-data-dir=<some directory></pre>
|
|
|
|
<p>Now you can navigate to the given port from your <i>client</i> and attach to
|
|
any of the discovered tabs for debugging: <a href="http://localhost:9222">http://localhost:9222</a>
|
|
</p>
|
|
|
|
<p>You will find the 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 exchanging 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 requesting: <a href="http://localhost:9222/json">http://localhost:9222/json</a> 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>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>
|
|
|
|
<h4>Sniffing the protocol</h4>
|
|
<p>You can inspect how the Chrome DevTools uses the protocol. This is especially handy when looking up newer features. First, run Chrome with the debugging port open: <pre><code>/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --remote-debugging-port=9222 http://localhost:9222 http://chromium.org</code></pre> Then, select the Chromium Projects item in the <em>Inspectable Pages</em> 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. </p>
|
|
|
|
<figure class="screenshot">
|
|
<a href="debugger-protocol/debugger-protocol-sniffing-full.png" style="text-align: center; display:block;">
|
|
<div style="
|
|
background: url(https://developer.chrome.com/devtools/docs/debugger-protocol/debugger-protocol-sniffing-full.png) no-repeat;
|
|
text-indent: -999em;
|
|
background-size: cover;
|
|
height: 260px;
|
|
background-position-y: -122px;
|
|
">
|
|
<img src="debugger-protocol/debugger-protocol-sniffing.png" alt="Sniffing the debugger protocol">
|
|
</div>
|
|
Screenshot of sniffing the DevTools protocol with DevTools
|
|
</a>
|
|
</figure>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="collapsible">
|
|
<h2 id="clients">Debugging Protocol Clients</h2>
|
|
<p>Many applications and libraries already use the protocol. Some to collect
|
|
performance data, others to breakpoint debug from another editor. There are
|
|
libraries to access the raw protocol from Node.js and Python.
|
|
</p>
|
|
|
|
<p>Many of these clients are showcased here: <a href="https://developer.chrome.com/devtools/docs/debugging-clients">Showcased Debugging Protocol Clients</a>.
|
|
</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>Opening embedded Developer Tools will <a href="#simultaneous">terminate</a> the
|
|
remote connection and thus detach the extension.
|
|
</p>
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="collapsible">
|
|
<h2 id="simultaneous">Simultaneous protocol clients</h2>
|
|
<p>
|
|
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, <a href="https://code.google.com/p/chromium/issues/detail?id=129539">crbug.com/129539</a> follows the issue; you can star it for email updates.
|
|
</p>
|
|
<p>
|
|
Upon disconnnection, the outgoing client will receive a <code>detached</code> event. For example: <code>{"method":"Inspector.detached","params":{"reason":"replaced_with_devtools"}}</code>. View the <a href="https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/chrome/common/extensions/api/debugger.cc&q=file:debugger.cc%20Reason%20ParseReason&sq=package:chromium&type=cs&">enum of possible reasons.</a> (For reference: the <a href="https://chromiumcodereview.appspot.com/11361034/">original patch</a>). After disconnection, some apps have chosen to pause their state and offer a reconnect button.
|
|
</p>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
{{/partials.standard_devtools_article}}
|