Interviewer, I implemented a Chrome Devtools

[[426371]]

Web pages will load resources, run JS, render interfaces, store data, etc. How can we see the execution status when developing? Use the debugging tool chrome devtools. It supports dom debugging, JS debugger, local storage display, runtime profile, etc.

The same is true for Node.js, but it only supports JS debugger and profile. We can debug through chrome devtools or vscode debugger.

These tools are all remotely attached to the running program for debugging. How do they exchange data? Through webSocket. In addition, the chrome devtools protocol is also formulated to specify what capabilities and how to communicate.

This websocket-based debugging protocol is called the chrome devtools protocol. Because it has many functions, it is divided into multiple domains (complex things are usually divided into domains), including DOM, Debugger, Network, Page, etc., each with a different debugging protocol. Chrome devtools implements debugging through this protocol.

The new version of Chrome (Canary version) can turn on the Protocol Monitor panel of the experimental features in the settings.

You can see the transmitted CDP data:

This is the principle of chrome devtools.

What is the use of understanding this principle?

We can re-implement the server, and as long as the debugging protocol is connected, we can use chrome devtools to debug.

For example, how does Kraken (rendering CSS to Flutter) use Chrome DevTools to debug DOM and styles? It is by connecting to this protocol.

We can re-implement the client, and as long as it is connected to this protocol, we can use any tool to debug web pages/Node.js.

You can debug Node.js and web pages with chrome devtools, vscode debugger, or webstorm debugger. Why? Because they are all connected to this protocol.

So can we connect to this protocol to implement a debugging tool similar to Chrome DevTools?

Let's experiment:

We start Chrome and specify the debugging port via --remote-debugging-port:

 /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --remote-debugging-port=9222  

Then connect it.

Here we don't need to connect to the protocol directly. Chrome provides SDKs in various languages ​​and we can just call the API:

Let's connect to Chrome first:

 const CDP = require( 'chrome-remote-interface' ); 
 
 async function test() {
 let client;
 try {
 client = await CDP();
        const { Page, DOM, Debugger } = client;
 //...
 } catch(err) {
 console.error(err);
 }
 }
 test();

Then open baidu.com, wait 2 seconds, and take a screenshot:

 const CDP = require( 'chrome-remote-interface' );
 const fs = require( 'fs' ); 
 
 async function test() {
 let client;
 try {
 client = await CDP();
        const { Page, DOM, Debugger } = client; 
 
 await Page.enable();
        await Page.navigate({url: 'https://baidu.com' }); 
 
        await new Promise(resolve => setTimeout(resolve, 2000)); 
  
        const res = await Page.captureScreenshot();
        fs.writeFileSync( './screenshot.jpg' , res.data, {
            encoding: 'base64'  
 });
 } catch(err) {
 console.error(err);
 }
 }
 test();

Check out the effect:

In this way, we have run through the first section of CDP code.

The rest of the functions, including Network, Debugger, DOM, etc., can also be realized. Let's try it briefly:

 await DOM.enable(); 
 
 const { root } = await DOM.getDocument({
 depth: -1
 });

Depth is the depth. Setting it to -1 means returning the entire DOM:

With this data, can we browse the DOM?

There is also DOM.setAttributeValue to set attributes, DOM.getBoxModel to get the box model size, etc.

Based on these, it should be no problem for us to make a DOM editor.

And the network part:

 await Network.enable();
 Network. on ( 'responseReceived' , async evt => {
    const res = await Network.getResponseBody({
        requestId: evt.requestId
 }); 
 
    console.log(evt.response.url);
 console.log(res.body);
 });

We listen to each response through the responseReceived event, and then get the content of the response through Network.getResponseBody:

Based on this, we should have no problem implementing the Network panel functionality.

You can also connect to the profiler:

 await Profiler.start();
 await new Promise(resolve => setTimeout(resolve,2000));
 const { profile } = await Profiler.stop();

With this data, we can draw a flame graph through canvas.

Theoretically, we can implement all the functions of Chrome DevTools. Moreover, it is possible to debug a web page with multiple debugging tools at the same time, because websocket can have multiple clients.

You might ask, what's the point of implementing Chrome DevTools yourself?

When people do open source front-end projects, they usually write a NetEase Cloud Music client because there is ready-made data to use. So why not make a Chrome DevTools? There is also ready-made data, just start the browser, and it is so high-end.

We don't need to implement the complete chrome devtools. We can implement the network part, the DOM part, and the debugger part separately. We can make different UIs and have functions and interactions that chrome devtools don't have.

For example, if you are interviewing for a visualization position, and you say that you have connected to the profiler part of the chrome devtools protocol and used canvas to draw a flame chart, it will add a lot of extra points.

Summarize

Chrome debugging communicates with the debugging client through WebSocket, and has developed the Chrome Devtools Protocol, which is also used by Node.js, but the protocol is called V8 debugger protocol. We can see all CDP protocol request responses through the protocol monitor panel.

The CDP server can be implemented to connect to the debugging function of chrome devtools and debug different targets, such as the kraken rendering engine.

You can implement CDP client to debug with different tools, such as vscode debugger, webstorm debugger, etc.

We can also connect to the CDP server through the SDK API to get data and implement debugging functions. For example, we can implement DOM editor, Network viewer, JS Debugger, Profiler and flame graph separately, and we can achieve more powerful functions and better interaction than Chrome DevTools.

When you want to do an open source project but don't have data, you might as well consider making a CDP client. Isn't this better than the Cloud Music project?