[Bug] Extension mode: navigating to linkedin.com/messaging always drops the relay connection and orphans the tab (crash on 0.0.77, silent disconnect on 0.0.78)

[carlosfinocchiaro]

Environment

• @playwright/mcp: reproduced on 0.0.77 and 0.0.78 (extension mode)
• Playwright MCP Bridge extension: 0.2.1
• macOS 26.5.2 (arm64), Chrome stable, Node v24.15.0
• Transport: stdio ClientSession (also reproduced over streamable HTTP)

Summary

In --extension mode, browser_navigate to https://www.linkedin.com/messaging/ (logged-in session) drops the extension relay connection every single time. The page itself loads fine in the tab, but the tab falls out of the Playwright tab group, the relay WebSocket closes, and the next tool call fails. Navigation to other LinkedIn routes (/feed/, /jobs/, /notifications/) works and stays attached.

On 0.0.77 the failure mode is worse: the navigate call itself crashes with

TypeError: Cannot read properties of undefined (reading 'url')

and the session stays wedged (every subsequent browser_navigate returns the same TypeError until a full server restart). On 0.0.78 the crash is gone (matches the v0.0.78 release note "browser_navigate no longer crashes the response when navigation closes the last tab") and the session self-recovers on the next call with a fresh Welcome/connect.html attach — but the underlying disconnect + orphaned tab still happens on every attempt.

Deterministic reproduction (10/10 in our testing)

1. Start @playwright/mcp --extension with the Bridge extension token; the Welcome (connect.html) tab appears.
2. browser_navigate → https://www.linkedin.com/feed/ (logged-in LinkedIn) — works, ~7s, tab stays in group.
3. browser_navigate → https://www.linkedin.com/messaging/ — returns in ~2.6s:
   • 0.0.77: TypeError: Cannot read properties of undefined (reading 'url')
   • 0.0.78: reports success, but the next call fails with Target page, context or browser has been closed; a subsequent call re-attaches with a NEW Welcome tab. The messaging tab is left orphaned outside the group.

Variations tested: messaging directly from the Welcome tab — same result; via /notifications/ first — same result; waiting 75s on the feed before navigating — same result. /feed/→/jobs/ and all other route pairs we tried never disconnect.

DEBUG=pw:mcp* excerpt at the failure moment (0.0.78)

pw:mcp:relay → Playwright: Network.loadingFailed
pw:mcp:relay → Playwright: Log.entryAdded
pw:mcp:test delete http session
pw:mcp:test close browser
pw:mcp:relay closing extension connection: Playwright client disconnected
pw:mcp:relay Playwright WebSocket closed
pw:mcp:server:response callResult { ... '### Open tabs\nNo open tabs. Navigate to a URL to create one.' }
pw:mcp:relay Extension WebSocket closed: undefined

Impact

LinkedIn messaging is effectively unreachable via browser_navigate in extension mode; each attempt costs an orphaned tab. In long-running agent setups the 0.0.77 crash additionally wedged the whole session (we've since pinned 0.0.78).

Happy to run further diagnostics — the repro is fully deterministic on our side.

[dcrousso]

there appear to be two issues here that happen as a result of navigating to /messaging/

1. the TypeError happens in the response builder when there's no tabs left, which was previously fixed in fix(cli): don't crash the response when navigating closes the last tab #41675 but later reverted in Revert "fix(cli): don't crash the response when navigating closes the last tab" #41931 (though this was about chrome://extensions so it may be unrelated)

2. the orphaned tab is i think by design in the extension as when the last controlled tab's debugger detaches, RelayConnection._checkLastTabDetached closes the whole relay WebSocket which then drops the CDP connection and tears down the session, only for the next call re-open a fresh connect.html tab, leaving the messaging tab orphaned

but i'm not really sure why /messaging/ (as opposed to /feed/ or /jobs/ or etc.) ends up with the tab being detached

the extension should only detach special pages (e.g. chrome:, edge:, devtools:, etc.) so this seems like something else

could you grab a timestamped log from the extension's ServiceWorker around the failure with the following:

• tabId and reason for any chrome.debugger.onDetach
• groupId for any chrome.tabs.onReplaced
• groupId for any chrome.tabs.onRemoved
• groupId for any chrome.tabs.onUpdated

the reason should hopefully tell us why the tab was detached

[carlosfinocchiaro]

Thanks for the pointers — we instrumented the extension ServiceWorker exactly as requested (snippet below) and have an update, though not the one we expected.

The failure no longer reproduces in the original environment. Same machine (macOS 26.5.2 arm64), same logged-in LinkedIn account, Bridge extension still 0.2.1, server pinned @playwright/mcp@0.0.78: 3/3 clean runs today of the exact sequence that failed 10/10 on Jul 16-18 (/feed/ → 10s pause → /messaging/ → follow-up call). The relay stays up, the tab stays in its group, and browser_tabs works after the messaging navigation.

What changed since the failing window: Chrome auto-updated to 150.0.7871.129 (we don't have the exact failing-era build, but the report window was Jul 16-18). Possibly relevant: LinkedIn now immediately client-redirects /messaging/ → /messaging/thread/<id>/ on both accounts we tested; we can't say whether it did that during the failing window.

Instrumented captures from the healthy runs (two environments — the originally-failing macOS setup and a Windows 11 + different-account control): across all runs, zero chrome.debugger.onDetach and zero tabs.onReplaced fired at the messaging navigation; the only events are a normal tabs.onUpdated series on the single grouped tab (loading → title → complete, groupId constant throughout, groupId=-1 only at client disconnect). So in the healthy state there's no tab replacement — if the failing state was a prerender/portal activation swap, it isn't happening anymore. Happy to attach the full timestamped console logs + pw:mcp:relay traces if useful.

We're keeping the instrumentation snippet on hand; if this regresses (Chrome or LinkedIn change) we'll capture the four signals around a real failure immediately. Also fine with closing as not-reproducible-after-Chrome-update if you prefer — the 0.0.78 crash-fix half is confirmed good on our side.

ServiceWorker instrumentation used (paste into the extension SW console)

(() => {
  const ts = () => new Date().toISOString();
  const groups = new Map();          // tabId -> last-known groupId
  chrome.tabs.query({}).then(tabs => tabs.forEach(t => groups.set(t.id, t.groupId)));

  chrome.debugger.onDetach.addListener((source, reason) => {
    console.log(`[41917][${ts()}] debugger.onDetach tabId=${source.tabId} reason=${reason} lastKnownGroupId=${groups.get(source.tabId)}`);
  });
  chrome.tabs.onReplaced.addListener((addedTabId, removedTabId) => {
    const removedGroup = groups.get(removedTabId);
    chrome.tabs.get(addedTabId).then(t => {
      groups.set(addedTabId, t.groupId);
      console.log(`[41917][${ts()}] tabs.onReplaced added=${addedTabId} (groupId=${t.groupId} url=${t.url}) removed=${removedTabId} (lastKnownGroupId=${removedGroup})`);
    });
  });
  chrome.tabs.onRemoved.addListener((tabId, info) => {
    console.log(`[41917][${ts()}] tabs.onRemoved tabId=${tabId} lastKnownGroupId=${groups.get(tabId)} windowClosing=${info.isWindowClosing}`);
    groups.delete(tabId);
  });
  chrome.tabs.onUpdated.addListener((tabId, change, tab) => {
    groups.set(tabId, tab.groupId);
    console.log(`[41917][${ts()}] tabs.onUpdated tabId=${tabId} groupId=${tab.groupId} change=${JSON.stringify(change)}`);
  });
  console.log(`[41917][${ts()}] instrumentation armed`);
})();

[dcrousso]

ok ill close this for now. please let us know if you encounter this again. thanks!