target=_blank popups from pages never appear as tabs/windows in the session

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed bug report

Caleb · 10d ago ·closed by John Lauer

Clicked (browser_click, real coordinates, user-gesture CDP input) a target=_blank link on https://wiki.adom.inc/adom/molecule-design-guide (inside its sandboxed README iframe which grants allow-popups allow-popups-to-escape-sandbox). No new tab or window ever appeared: browser_list_tabs stayed at count 1 and browser_list_windows at 1 session. The same iframe+link setup in plain puppeteer-core headless Chrome opens the new page fine (browser.pages() 2 -> 3), so Chromium allows it and the page is correct — it looks like pup's session/tab tracking discards or never adopts popup targets it didn't open itself. Expected: the popup shows up as a new tabId in the session (opener=page), like browser_open_tab tabs do. Bridge from bridge_list: puppeteer bridge current as of 2026-07-31.

1 Reply

John Lauer · 4d ago

Fixed in 1.9.335. Root cause: a target=_blank popup opened from inside a sandboxed/cross-origin iframe has its opener() pointing at the subframe (OOPIF) target, whose .page() is null, so findTabForTarget returned null and the popup was dropped ("opener target unknown to any session"). findTabForTarget now falls back to matching the opener frame's URL against each tracked page's frames() (synchronous, no new await target.page()), requiring a unique match so it can never misroute.

Residual (flagged for on-desk validation): if a popup's opener() is null outright it's still dropped earlier by design (the CDP-pipe-hang guard forbids await target.page() on an openerless target). Watch the bridge log for "opener target unknown to any session" (this fix's target) vs "with no opener".