fix(chromium): keep closing the target so page.close() cannot hang on a navigation commit#41912
fix(chromium): keep closing the target so page.close() cannot hang on a navigation commit#41912dcrousso wants to merge 1 commit into
Conversation
dcrousso
changed the title
… a commit race `page.close()` has no timeout and resolves only once the browser reports `Target.detachedFromTarget` if the close happens at the same time as a navigation commit, the `Target.closeTarget` responds with success but silently drops the actual close (crbug.com/536385539) repeatedly dispatch `Target.closeTarget` until the target actually detaches (note that a close on an already-closing target is a no-op)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Test results for "MCP"7786 passed, 1249 skipped Merge workflow run. |
Test results for "tests 1"1 failed 4 flaky50016 passed, 1192 skipped Merge workflow run. |
| // actually doesnt do anything, leaving the target alive and causing this to hang forever (crbug.com/536385539). | ||
| const closed = crPage._page.closedPromise.then(() => true); | ||
| while (true) { | ||
| await this._session.send('Target.closeTarget', { targetId: crPage._targetId }).catch(() => {}); |
There was a problem hiding this comment.
Let's fix it upstream. This is clearly a bug in the close command.
🟢 CI is clear — the one failure is a pre-existing flakeHi, I'm the Playwright bot and I took a first look at the failing CI. The only real failure — DetailsThis PR only changes Chromium Pre-existing flake / infra
Flaky (rescued on retry, nothing to triage)
These passed on retry and are unrelated to the Chromium close path. I'm a first pass, not the final word — but this one looks safe to ignore. Triaged by the Playwright bot - agent run |
2 participants
page.close()has no timeout and resolves only once the browser reportsTarget.detachedFromTargetif the close happens at the same time as a navigation commit, the
Target.closeTargetresponds with success but silently drops the actual close (crbug.com/536385539)repeatedly dispatch
Target.closeTargetuntil the target actually detaches (note that a close on an already-closing target is a no-op)this fix is very similar to #41695
fixes #41900