Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: fd143209a425a1b3dafaca50b2f6ff9a7fa153bc
https://github.com/WebKit/WebKit/commit/fd143209a425a1b3dafaca50b2f6ff9a7fa153bc
Author: Basuke Suzuki <[email protected]>
Date: 2026-05-29 (Fri, 29 May 2026)
Changed paths:
M Source/WebKit/UIProcess/SuspendedPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] Restoring a page with a cross-site iframe from the
back/forward cache terminates the iframe process due to a stale first party for
cookies
https://bugs.webkit.org/show_bug.cgi?id=315798
rdar://178189215
Reviewed by Sihui Liu.
Under Site Isolation with MultiProcessBackForwardCacheEnabled,
restoring a page from the
back/forward cache after a cross-site navigation goes through
SuspendedPageProxy::unsuspend(),
which dispatches RestoreWithFrameItem to each cached iframe process so it can
restore its own
cached page.
The cross-site main-frame navigation (a.com -> b.com) broadcasts the new top
document's
DocumentSyncData (the b.com URL) to every web-content process, including the
to-be-suspended
frame.com iframe process, overwriting its top document sync state. On goBack,
the iframe restore
(CachedPage::restore -> FrameLoader::open -> updateFirstPartyForCookies) reads
the page's
main-frame URL, which is still the stale b.com value, so the first party for
cookies resolves to
b.com instead of the a.com main frame. The NetworkProcess then denies the access
(b.com is not an allowed first party for the a.com page) and terminates the
iframe process. This
early first-party read happens before the main frame's own restore
re-broadcasts a.com's sync
data, so the iframe
never sees the correction in time.
Fix this by having the UIProcess pass the authoritative main-frame URL and
origin into the
cross-site restore. RestoreWithFrameItem now carries an optional main-frame URL
+
SecurityOriginData; SuspendedPageProxy::unsuspend (the cross-site sender)
supplies it from the
suspended main frame (its committed URL and SecurityOrigin, so sandbox/opaque
cases are
preserved), and the iframe WebProcess calls Page::setMainFrameURLAndOrigin
before restoring the
cached page. The remaining top document sync state is re-established by the
main frame's own
restore re-broadcast. WebPageProxy::goToBackForwardItem, the same-site
in-process restore path,
does not exhibit this bug (the top URL stays on the a.com site) and has no
authoritative
restore-target origin, so it passes nullopt and is unchanged.
Strengthen GoBackToPageWithIframeBFCache to mark the cross-site frame.com
iframe document before
navigating away and to read both that marker and
document.cookie from the iframe scope after
restore, tying the verification to the iframe process surviving and its
first-party-for-cookies
access succeeding.
* Source/WebKit/UIProcess/SuspendedPageProxy.cpp:
(WebKit::SuspendedPageProxy::unsuspend):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::goToBackForwardItem):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::restoreWithFrameItem):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TEST(SiteIsolation, GoBackToPageWithIframeBFCache)):
Canonical link:
https://flagged.apple.com:443/proxy?t2=Dv9p2v5Ul6&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE0MTk5QG1haW4=&emid=8b636e1c-5aec-453e-8b8a-380b23a49f4f&c=11
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
