Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 715819851adf00d75cf2bce3b734e44167aa3906
      
https://github.com/WebKit/WebKit/commit/715819851adf00d75cf2bce3b734e44167aa3906
  Author: Sihui Liu <[email protected]>
  Date:   2026-09-28 (Mon, 28 Sep 2026)

  Changed paths:
    M Source/WebKit/Shared/WebBackForwardListFrameItem.cpp
    M Source/WebKit/Shared/WebBackForwardListFrameItem.h
    M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm

  Log Message:
  -----------
  [Site Isolation] Back/forward loads can swap the history state of sibling 
iframes
https://bugs.webkit.org/show_bug.cgi?id=325464
rdar://188558687

Reviewed by Basuke Suzuki.

When a back/forward load recreates a page's iframes (a back/forward cache miss, 
a session restore, or restoring the
back/forward list into a new web view), each child frame asks the UI process 
for its state. The new frames have new
frame identifiers, so for unnamed iframes the UI process falls back to looking 
up the child item at the frame's index
among its siblings.

WebBackForwardListFrameItem::setChild() appended child items in commit order. A 
cross-site iframe has to set up a
provisional frame in another process before committing, so it usually commits 
after a later same-site sibling. For a
page with a cross-site iframe followed by a same-site iframe, the children 
ended up as [same-site, cross-site] while the
frame tree is [cross-site, same-site]. After going back, the first iframe 
loaded the same-site URL in the main frame's
process, the second loaded the cross-site URL, and each got the other's scroll 
position and form state.

Fix this by inserting a new child item before the first existing child whose 
frame is still alive, has the same parent,
and comes later among its siblings in the UI frame tree. Existing children with 
the same frame identifier are still
replaced in place, and children without a live frame keep their relative order. 
This keeps children in the order the
lookup expects. Both the C++ and Swift WebBackForwardList go through 
setChild(), so both are fixed.

Tests: SiteIsolation.GoBackToCrossSiteIframeCommittedAfterSameSiteSibling
       
SiteIsolation.GoBackToCrossSiteIframeCommittedAfterSameSiteSiblingAfterSessionRestoreToNewWebView

* Source/WebKit/Shared/WebBackForwardListFrameItem.cpp:
(WebKit::WebBackForwardListFrameItem::setChild):
(WebKit::WebBackForwardListFrameItem::insertionIndexForChild const):
* Source/WebKit/Shared/WebBackForwardListFrameItem.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::testGoBackToCrossSiteIframeCommittedAfterSameSiteSibling):
(TestWebKitAPI::TEST(SiteIsolation, 
GoBackToCrossSiteIframeCommittedAfterSameSiteSibling)):
(TestWebKitAPI::TEST(SiteIsolation, 
GoBackToCrossSiteIframeCommittedAfterSameSiteSiblingAfterSessionRestoreToNewWebView)):

Canonical link: https://commits.webkit.org/322127@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to