Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e403c05b190ece3f5e3142a05509141c99174187
https://github.com/WebKit/WebKit/commit/e403c05b190ece3f5e3142a05509141c99174187
Author: Basuke Suzuki <[email protected]>
Date: 2026-05-11 (Mon, 11 May 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
[Site Isolation] WebPage::frameTreeSyncDataChangedInAnotherProcess should not
ASSERT on stale cross-process IPC
https://bugs.webkit.org/show_bug.cgi?id=314584
rdar://176824128
Reviewed by Ryosuke Niwa.
WebPage::frameTreeSyncDataChangedInAnotherProcess ASSERTs
ASSERT(frame->page() == this);
But cross-process frame-tree sync messages can legitimately arrive at a
WebPage that no longer owns the WebFrame. This happens during multi-process
BFCache lifecycle transitions where two sibling WebPages exist in the same
process (one suspended, one active), and a sync message originally routed
for one view arrives at the other after a suspend/restore transition.
The ASSERT crashes the WebContent process in Debug. In Release the ASSERT is
compiled out and the function silently performs
coreFrame->updateFrameTreeSyncData(data) on a frame in a different WebPage,
which is harmless because the frame's own WebPage will receive the same
update through its own IPC routing.
Convert the ASSERT to a soft-check that returns early on mismatch, so the
function consistently ignores stale or mis-routed updates in both Debug and
Release. Aligns with the defensive-coding pattern used elsewhere for
cross-process IPC routing during page lifecycle transitions.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::frameTreeSyncDataChangedInAnotherProcess):
Canonical link: https://commits.webkit.org/313048@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
