Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 22fa960e41397c6c2fd972209abfe04df4dfb6ae
https://github.com/WebKit/WebKit/commit/22fa960e41397c6c2fd972209abfe04df4dfb6ae
Author: Basuke Suzuki <[email protected]>
Date: 2026-07-06 (Mon, 06 Jul 2026)
Changed paths:
M Source/WebCore/history/BackForwardCache.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] Back navigation to an intermediate multi-process BFCache
entry hangs when a cross-site iframe could not be cached
https://bugs.webkit.org/show_bug.cgi?id=318475
rdar://181270033
Reviewed by Sihui Liu.
Under Site Isolation with multi-process back/forward cache, a same-site
main-frame history chain (a -> b -> c) where each entry hosts a cross-site
iframe could hang when navigating back to an intermediate entry.
A cross-site subframe web process hosts a single WebPage with one
m_isSuspended flag, and BackForwardCache suspension operates on that one live
corePage(). When the first main-frame entry (a) is cached, the iframe process
suspends its single live page. When the UIProcess later asks it (via
SuspendWithFrameItem) to also cache the intermediate entry (b), the WebPage is
already suspended and its single live corePage() cannot be suspended again, so
b's iframe subframe is never added to that process's BackForwardCache.
WebPage::suspendWithFrameItem's already-suspended early-return replied
completionHandler(true) -- a false success -- so
WebPageProxy::didCacheBackForwardItem
recorded b as having cached iframe children it never had. On back-navigation to
b, RestoreWithFrameItem -> BackForwardCache::take returned NOT-FOUND, the
restore
aggregator failed, and the UIProcess fell back to reload(ExpiredOnly), which
never fired didFinishNavigation, so the navigation hung until timing out.
Return the honest answer instead: whether this frame item is actually cached in
this process (isInBackForwardCache(identifier)). That is true for an idempotent
re-suspend of the same entry and false when the WebPage is suspended for a
different entry -- mirroring addIfCacheable's own return value. The false makes
the UIProcess discard b's unbacked entry, so back-to-b falls back to a normal
load that completes.
This is a targeted fix for the hang. The underlying limitation it works around
-- an iframe process can hold only one cached main-frame entry per WebPage --
still caps multi-entry BFCache coverage under Site Isolation and will be
addressed by a larger redesign (moving cached-entry ownership from the single
per-process WebPage down to a per-BFCache-entry frame snapshot), tracked in
https://bugs.webkit.org/show_bug.cgi?id=318474 (rdar://181269874).
* Source/WebCore/history/BackForwardCache.h: Export isInBackForwardCache.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::suspendWithFrameItem): Report whether the frame item is
actually cached rather than an unconditional success when already suspended.
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::TEST): Add
MultiProcessBFCacheGoBackToIntermediateEntryDoesNotHang.
Canonical link: https://commits.webkit.org/316605@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
