list_network_requests misses navigation requests in tabs opened via window.open

Is your feature request related to a problem? Please describe.

Description of the feature

When a page opens a new tab itself (window.open / target=_blank from a click handler), list_network_requests on that tab returns nothing — the entire navigation, redirect chain included, is missed. includePreservedRequests: true doesn't help; nothing was ever recorded. Quiet failure: an empty listing reads as "this tab made no requests".

Cause: new targets are wired reactively (McpContext.ts — targetcreated → await target.page() → void #createMcpPage(page)), so the popup navigates before the collector's Network.enable lands. And unlike console messages (#2382), Chromium doesn't replay network events to late CDP sessions, so there's nothing to backfill.

Reproduction

1. new_page →

   data:text/html,<a href="#" onclick="window.open('https://httpbingo.org/redirect-to?url=https%253A%252F%252Fexample.com%252F','_blank');return false;">OPEN</a>
   

2. take_snapshot, click the link

3. list_pages → the popup is there, already landed on https://example.com/ (redirect chain completed)

4. select_page the popup, list_network_requests with includePreservedRequests: true → empty

Sanity check: navigate that same popup anywhere afterwards and the request shows up fine — capture works, it just started too late.

Describe the solution you'd like

Expectation

Requests in opened tabs are captured from the first request. Since CDP offers no replay for Network events, the reliable shape seems to be pausing new targets until the collector is wired: Target.setAutoAttach with waitForDebuggerOnStart: true, enable Network on attach, then Runtime.runIfWaitingForDebugger.

Proposal

The proposed solution is to hold old new targets until the collector is wired: browser-level Target.setAutoAttach with waitForDebuggerOnStart: true, enable Network on attach, then Runtime.runIfWaitingForDebugger. The pause is a few milliseconds per new tab.

Enabling it could work like this:

• a server flag, e.g. --captureNewTabs, enabling pause-and-wire globally; or
• a runtime tool to arm it on demand

Describe alternatives you've considered

• includePreservedRequests — doesn't apply: it preserves already-captured requests across navigations, and here nothing was ever captured.
• --chromeArg=--auto-open-devtools-for-tabs — verified, no effect: the held first navigation feeds the DevTools frontend's own CDP session, not the server's.
• External sidecar: a second CDP client that arms setAutoAttach itself and logs Network events (our current workaround), but lives outside the server and its capture is invisible to list_network_requests, so results come from two sources.

Additional context

Context: we run browser-ground-truth tests, where verifying click → redirect chain → landing is the whole point. The chain start is exactly the part that's lost.

Chrome DevTools MCP version

1.6.0