Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 1732420d99b5d73dedbe3f4c35c65b039855a673
https://github.com/WebKit/WebKit/commit/1732420d99b5d73dedbe3f4c35c65b039855a673
Author: Sihui Liu <[email protected]>
Date: 2026-02-25 (Wed, 25 Feb 2026)
Changed paths:
M LayoutTests/fast/frames/frame-element-name-expected.txt
M
LayoutTests/http/tests/security/dataURL/xss-DENIED-from-data-url-in-foreign-domain-subframe-expected.txt
M Source/WebCore/page/FrameTree.cpp
M Source/WebKit/UIProcess/WebBackForwardList.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm
Log Message:
-----------
[Site Isolation] Back navigation might not restore state of cross-site frame
https://bugs.webkit.org/show_bug.cgi?id=308450
rdar://170956531
Reviewed by Charlie Wolfe.
With current implementation, sometimes back-forward navigation does not restore
cross-site frames on a page correctly.
This cause is subframe process creates back-forward list item with incorrect
target (frame unique name), so that when
the navigating web process tries to find child history item with target (see
FrameLoader::loadURLIntoChildFrame =>
HistoryItem::childItemWithTarget), it will not find correct history item for
frame to use.
Here is key flow of the issue:
1. When an iframe navigates cross-site, UI process starts the load in a
different web process.
2. The web process creates a remote frame and a provisional local frame for the
iframe, and starts load in local frame.
3. When the load is committed in provsional local frame, the web process asks
UI process to create a new backforward
list item, with the target (frame's unique name) inside (see
DocumentLoader::commitLoad => commitIfReady =>
FrameLoader::transitionToCommitted =>
HistoryController::updateBackForwardListClippedAtTarget).
4. Also at load commit time, the web process will also replace the remote frame
with the local frame in tree (see
DocumentLoader::commitLoad => commitData => FrameLoader::dispatchDidCommitLoad
=> WebFrame::commitProvisionalFrame()).
Normally, the target at step 3 should be a string based on frame's position in
tree. However, it is actually null
because FrameTree::uniqueName returns m_specifiedName (default to null) when
frame is not added to tree yet. In this
case, frame is only added to tree after step 4. But, FrameTree::uniqueName is
read and used in step 3. To fix this, make
sure FrameTree::uniqueName only returns null when frame is a top frame, or
frame has a non-null specified name. In other
cases, we still traverse the frame tree to generate correct unique name -- this
fix works in this case as the remote
frame is already in tree.
With this fix, the API test SiteIsolation.RestoreSessionFromAnotherWebView
starts to time out. Before the fix, when
doing back-forward navigation, FrameLoader::loadURLIntoChildFrame will not be
able to find child frame state with target
(HistoryItem::childItemWithTarget) since target is wrong, so it just treats the
iframe load as a normal navigation
initiated by web page, and browser context group will stay the same (see
browsingContextGroup setting logic in
WebPageProxy::receivedNavigationActionPolicyDecision). After the fix, the
iframe load will be treated as navigation
requested from client (as it's part of back-forward navigation from session
restore), so a new browsing context group
will be created for the navigation. As this is a new browsing context group,
BrowsingContextGroup::m_pages is empty. So,
RemotePageProxy will not be created, WebPage will not be created in navigating
process, and thus navigation will not
succeed. Browsing context group should never be changed for non-main frame
navigation -- all frames in the same page
should belong to the same BCG. So this patch fixes the issue by ensuring that.
(Credits to Basuke who found the test case.)
API Tests: WKBackForwardList.PageCacheGoBackAfterNavigatingSameSiteIframe2
WKBackForwardList.NoPageCacheGoBackAfterNavigatingSameSiteIframe2
* LayoutTests/fast/frames/frame-element-name-expected.txt:
*
LayoutTests/http/tests/security/dataURL/xss-DENIED-from-data-url-in-foreign-domain-subframe-expected.txt:
Rebaseline
test expectation, as the fix is a progression.
* Source/WebCore/page/FrameTree.cpp:
(WebCore::FrameTree::uniqueName const):
* Source/WebKit/UIProcess/WebBackForwardList.cpp:
(WebKit::WebBackForwardList::backForwardAddItemShared):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::browsingContextGroupForNavigation): This is a new helper
function to pick browsing context group.
Most of it is just the same as current implementation, with a fix to reuse same
BCG for iframe navigation.
(WebKit::WebPageProxy::receivedNavigationActionPolicyDecision):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm:
(runGoBackAfterNavigatingSameSiteIframe2):
(TEST(WKBackForwardList, PageCacheGoBackAfterNavigatingSameSiteIframe2)):
(TEST(WKBackForwardList, NoPageCacheGoBackAfterNavigatingSameSiteIframe2)):
Canonical link: https://commits.webkit.org/308220@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
