Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 5519b28fa3c8ac963b17993af1d5a89c6a9cf72a
https://github.com/WebKit/WebKit/commit/5519b28fa3c8ac963b17993af1d5a89c6a9cf72a
Author: Sihui Liu <[email protected]>
Date: 2026-07-23 (Thu, 23 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] Fix
TestWebKitAPI.SiteIsolation.QueryFramesStateAfterNavigating
https://bugs.webkit.org/show_bug.cgi?id=319877
rdar://182779863
Reviewed by Basuke Suzuki.
WebPageProxy::didCacheBackForwardItem() only detached the outgoing document's
child frames from the main frame
(mainFrame->takeChildFrames()) after checking activeRemoteFrameProcesses() and
bailing out early when that list was
empty. When a navigation reuses the same process and the old page only contains
same-site frames, the early return
means the detachment never happened, and the old page's _WKFrameTreeNode
children stays attached to the main frame after
the new page loaded its own children on top of them. To fix this, move the
takeChildFrames() call above the
activeRemoteFrameProcesses() early-out so it always runs when Site Isolation
and multi-process back/forward cache are
enabled, regardless of whether the navigation happens to change process.
Also, call relaxAdoptionRequirement() in RemotePageProxy's constructor:
RemotePageProxy registers itself with other
objects before it is wrapped in a Ref/RefPtr via adoptRef(), which otherwise
trips the adoption assertion
`ASSERT(!m_adoptionIsRequired);`.
That fix has a side effect on the back/forward cache restore path.
WebBackForwardCacheEntry::takeForRestoration() now
returns a non-empty cachedChildren list for same-process iframes, whereas
before it was always empty in this case since
setCachedChildren() was never reached. Its companion iframeProcesses list is
computed by walking the cached children's
processes with no exclusion for the process the main frame is restoring into,
unlike the analogous suspend-side
activeRemoteFrameProcesses(), which explicitly skips the main frame's own
process. As a result,
WebPageProxy::goToBackForwardItem() now iterates the main frame's own process
in iframeProcesses, looks up a
RemotePageProxy for it via browsingContextGroup()->remotePageInProcess(), finds
none (same-process children aren't
RemotePageProxy-backed), and calls aggregator->failed(). Since nothing else
chains the aggregator for that entry, it
resolves failure once the loop returns, which removes the just-stored
pendingBackForwardCachedChildren entry and calls
page->reload(ReloadOption::ExpiredOnly) -- discarding the back/forward cache
restore entirely and reloading from network
instead of reattaching the cached iframe. This produced a TIMEOUT in
imported/w3c/web-platform-tests/navigation-api/navigation-history-entry/entries-after-bfcache-in-iframe.html
on the
macOS-Sequoia-Release-Site-Isolation-Tests-EWS bot, since the test's iframe
never re-fires pageshow/navigation events
after the forced reload. Fix this by skipping iframe processes that match the
frame item's destination process in the
restore loop, mirroring activeRemoteFrameProcesses()'s exclusion on the suspend
side; same-process children need no
RestoreWithFrameItem round-trip since they are already reattached directly via
pendingBackForwardCachedChildren/adoptChildFrames in didCommitLoadForFrame once
the main frame commits.
Finally, update the test to enable Site Isolation on its own, like other tests
in the same file, so that the test
validates SI behavior on non-SI bots.
API tests: SiteIsolation.QueryFramesStateAfterNavigating
SiteIsolation.QueryFramesStateAfterGoingBackToCachedPageWithIframe
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::goToBackForwardItem):
(WebKit::WebPageProxy::didCacheBackForwardItem):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation, QueryFramesStateAfterNavigating)):
(TestWebKitAPI::TEST(SiteIsolation,
QueryFramesStateAfterGoingBackToCachedPageWithIframe)):
Canonical link: https://commits.webkit.org/317786@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
