fix(chromium): prevent TargetClosedException on main-frame cross-process navigation

[karimnabli]

Fixes #41348

Root Cause

In crPage.ts, the _onDetachedFromTarget method assumes that a detached target implies either a swap or a true detach. However, Azure OAuth introduces a third case: a main-frame cross-process navigation.

Due to the microtask delay in Page.enable, the session mapping changes, and Playwright incorrectly calls frameDetached, throwing a TargetClosedException immediately after the "Stay signed in?" click.

Fix

Added a guard in _onDetachedFromTarget to verify if the session currently mapped to the targetId is still the childFrameSession that triggered the detachment. If a new session has taken over (indicating a cross-process navigation), we skip the frameDetached call and simply dispose of the old session.

Test

Added a regression test in tests/library/chromium/oopif.spec.ts that simulates a cross-origin redirect after a form submission to ensure the page survives the transition.

[karimnabli]

@microsoft-github-policy-service agree

[karimnabli]

@pavelfeldman @dgozman

I’ve implemented a fix for #41348

Root cause:
In crPage.ts, _onDetachedFromTarget assumes a detached target is either a swap or a true detach. However, Azure OAuth introduces a third case: a main-frame cross-process navigation. Due to the microtask delay in Page.enable, the session mapping changes and Playwright incorrectly calls frameDetached, leading to a TargetClosedException right after the "Stay signed in?" click.

Fix:
Added a guard in _onDetachedFromTarget to verify whether the session currently mapped to the targetId is still the childFrameSession that triggered the detachment. If a new session has taken over (cross-process navigation), the frameDetached call is skipped and the old session is simply disposed.

Test:
Added a regression test in tests/library/chromium/oopif.spec.ts that simulates a cross-origin redirect after form submission to ensure the page survives the transition.

Could you please review whether this approach aligns with the expected handling of cross-process navigations?

[github-actions]

Test results for "MCP"

3 failed
❌ [chrome] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-ubuntu-latest-chrome
❌ [chromium] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-chromium
❌ [firefox] › mcp/http.spec.ts:349 › client should receive list roots request @mcp-macos-latest-firefox

7458 passed, 1132 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

2 failed
❌ [chromium-library] › library/browsercontext-add-init-script.spec.ts:28 › should work without navigation, after all bindings @chromium-ubuntu-22.04-arm-node20
❌ [chromium-library] › library/browsercontext-expose-function.spec.ts:77 › should be callable from-inside addInitScript @chromium-ubuntu-22.04-arm-node20

7 flaky

⚠️ [chromium-library] › library/chromium/chromium.spec.ts:177 › serviceWorker(), and fromServiceWorker() work `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:177 › serviceWorker(), and fromServiceWorker() work `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:211 › should intercept service worker requests (main and within) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/tracing.spec.ts:430 › should produce screencast frames crop `@chromium-ubuntu-22.04-node22`
⚠️ [chromium-library] › library/video.spec.ts:680 › screencast › should capture full viewport on hidpi `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/trace-viewer.spec.ts:1630 › should highlight locator in iframe while typing `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-page] › page/page-emulate-media.spec.ts:144 › should keep reduced motion and color emulation after reload `@firefox-ubuntu-22.04-node20`

49170 passed, 1163 skipped

---

Merge workflow run.

[karimnabli]

Hi, @pavelfeldman @dgozman
Does these MCP
MCP / macos-latest - chromium (pull_request)
MCP / macos-latest - chromium (pull_request)Failing after 18m
MCP / macos-latest - firefox (pull_request)
MCP / macos-latest - firefox (pull_request)Failing after 28m
MCP / ubuntu-latest - chrome (pull_request)
MCP / ubuntu-latest - chrome (pull_request)Failing after 14m
tests 1 / ubuntu-22.04-arm (chromium - Node.js 20) (pull_request)
tests 1 / ubuntu-22.04-arm (chromium - Node.js 20) (pull_request)Failing after 18m
Are failing because of the changes in this PR ?

[karimnabli]

Hi, @pavelfeldman @dgozman @Skn0tt – I wanted to flag that the failing MCP test (tests/mcp/http.spec.ts:349 - "client should receive list roots request") appears to be a pre-existing flakiness issue unrelated to this PR.

Evidence:

• The test times out waiting for the MCP server to send a ListRootsRequest, which is independent of Chromium's OOPIF/cross-process navigation handling
• This PR only modifies crPage.ts (OOPIF target session management) and adds a regression test for cross-origin redirects in oopif.spec.ts
• The same MCP test has failed intermittently on the main branch (e.g., workflow runs fix(test-runner): warn users who invoke the test-runner with Jest #7743, [Feature]: Support 'em' units for page margins #7745), indicating it's a flaky test in the MCP test suite itself

My PR changes:

• Fixes a race condition in _onDetachedFromTarget where cross-process navigation was incorrectly triggering TargetClosedException
• Adds a guard to verify if the current session mapping has changed before calling frameDetached
• Includes a regression test for the specific cross-origin redirect scenario

The MCP job failure should not block this PR. If needed, I'm happy to see if this test flakiness can be addressed in a separate issue.

[dgozman]

I tried to run pretty much your exact test on the bots, without a fix, to see what's going wrong: #41930. Turns out, it passes on every bot. Now I am not sure we are fixing the right problem at all. We need some easy-ish repro that we can turn into a test to make sure we are fixing the actual issue.