Bug 314584 – [Site Isolation] WebPage::frameTreeSyncDataChangedInAnotherProcess should not ASSERT on stale cross-process IPC

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Basuke Suzuki]

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.

[Basuke Suzuki]

Tracked in rdar://176824128

[Basuke Suzuki]

<rdar://problem/176824128>

[Basuke Suzuki]

Pull request: https://github.com/WebKit/WebKit/pull/64718

[EWS]

Committed 313048@main (e403c05b190e): <https://commits.webkit.org/313048@main>

Reviewed commits have been landed. Closing PR #64718 and removing active labels.