chrome-devtools-automation

Connect to the DevTools front end as its own CDP target by launching Chrome with --remote-debugging-port and --auto-open-devtools-for-tabs, then open a WebSocket to the devtools:// target listed at /json. Send CDP commands like Runtime.evaluate and Input.dispatchMouseEvent over that socket.

Click the panel's tab element using real mouse input at its bounding-box center; stable tab ids include tab-network, tab-elements, and tab-resources for Application. If the tab is hidden in the overflow menu, use the Command Menu (Ctrl+Shift+P) with Input.insertText to run 'Show <panel name>'.

The entire DevTools UI is built from nested shadow roots, so a plain querySelector on the document cannot see inside them. You must recursively walk every element's shadowRoot, which the provided deep-query helpers do with depth and node-count limits.

No. Playwright and the page CDP session drive the page under test, not the DevTools front end, which is a separate CDP target. You must open a second WebSocket connection to the devtools:// target to script panels, trees, and toolbar buttons.

DevTools widgets ignore synthetic click() calls and respond only to real input events. Read the element's bounding box and dispatch Input.dispatchMouseEvent with mouseMoved, mousePressed, and mouseReleased at its center; the hover step matters because some buttons only accept presses once hovered.

A CDP socket interleaves events with responses, so reading one frame may return an event instead of your result; correlate on a unique request id. Large Runtime.evaluate payloads also span multiple frames, so reassemble until EndOfMessage before parsing.