RESOLVED FIXED315216
[Site Isolation] Don't seed new RemoteFrame with the dying LocalFrame's stale FrameTreeSyncData
https://bugs.webkit.org/show_bug.cgi?id=315216
Summary [Site Isolation] Don't seed new RemoteFrame with the dying LocalFrame's stale...
zak ridouh
Reported 2026-05-20 11:42:15 PDT
In WebFrame::loadDidCommitInAnotherProcess, the new RemoteFrame was seeded with the dying LocalFrame's FrameTreeSyncData, whose frameDocumentSecurityOrigin reflects the pre-swap document -- not the cross-origin document the frame is navigating to. The post-commit FrameTreeSyncDataChangedInAnotherProcess IPC arrives shortly to refresh this, but any task that queries the remote window in the meantime (e.g. a BroadcastChannel dispatch fired from pagehide) can observe a cached origin that spuriously matches the active document. BindingSecurity correctly denies the access (the target is remote), but DOMWindow::crossDomainAccessErrorMessage then asserts that active and target origins are not same-origin-domain, which flakily crashes the http/tests/site-isolation/page-lifecycle/{pagehide,pageswap,unload}.html tests. Seed the new RemoteFrame with an empty FrameTreeSyncData (opaque origin) instead, matching the pattern already used by WebFrame::createSubframe and WebFrameProxy::remoteProcessDidTerminate. The post-commit broadcast still arrives via the same IPC connection and supplies the real new values; until then, opaque is an honest "unknown" placeholder that never compares same-origin.
Attachments
Radar WebKit Bug Importer
Comment 1 2026-05-20 11:42:22 PDT
zak ridouh
Comment 2 2026-05-20 11:50:06 PDT
EWS
Comment 3 2026-05-20 18:13:41 PDT
Committed 313620@main (e5c4d1be155f): <https://commits.webkit.org/313620@main> Reviewed commits have been landed. Closing PR #65311 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.