314584 2026-05-11 14:41:56 -0700 [Site Isolation] WebPage::frameTreeSyncDataChangedInAnotherProcess should not ASSERT on stale cross-process IPC 2026-05-11 18:44:54 -0700 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 basuke basuke kkinnunen webkit-bug-importer oldest_to_newest 2209853 0 basuke 2026-05-11 14:41:56 -0700 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. Fix: convert the ASSERT to a soft-check that returns early on mismatch, so the function consistently ignores stale/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. 2209858 1 basuke 2026-05-11 14:50:21 -0700 Tracked in rdar://176824128 2209923 2 basuke 2026-05-11 17:34:06 -0700 <rdar://problem/176824128> 2209924 3 basuke 2026-05-11 17:34:40 -0700 Pull request: https://github.com/WebKit/WebKit/pull/64718 2209946 4 ews-feeder 2026-05-11 18:44:52 -0700 Committed 313048@main (e403c05b190e): <https://commits.webkit.org/313048@main> Reviewed commits have been landed. Closing PR #64718 and removing active labels.