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
-
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>
-
take_snapshot, click the link
-
list_pages → the popup is there, already landed on https://example.com/ (redirect chain completed)
-
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
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=_blankfrom a click handler),list_network_requestson that tab returns nothing — the entire navigation, redirect chain included, is missed.includePreservedRequests: truedoesn'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'sNetwork.enablelands. And unlike console messages (#2382), Chromium doesn't replay network events to late CDP sessions, so there's nothing to backfill.Reproduction
new_page→take_snapshot,clickthe linklist_pages→ the popup is there, already landed onhttps://example.com/(redirect chain completed)select_pagethe popup,list_network_requestswithincludePreservedRequests: true→ emptySanity 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.setAutoAttachwithwaitForDebuggerOnStart: true, enable Network on attach, thenRuntime.runIfWaitingForDebugger.Proposal
The proposed solution is to hold old new targets until the collector is wired: browser-level
Target.setAutoAttachwithwaitForDebuggerOnStart: true, enable Network on attach, thenRuntime.runIfWaitingForDebugger. The pause is a few milliseconds per new tab.Enabling it could work like this:
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.setAutoAttachitself 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