Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 86ad754c5241dc05eefb5ce157aa0967e3dfa785
https://github.com/WebKit/WebKit/commit/86ad754c5241dc05eefb5ce157aa0967e3dfa785
Author: Anthony Tarbinian <[email protected]>
Date: 2026-08-19 (Wed, 19 Aug 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] ad iframes auto-refresh after returning from ad clicks.
https://bugs.webkit.org/show_bug.cgi?id=321531
rdar://168602323
Reviewed by Charlie Wolfe.
With site isolation enabled, it's possible for a web process to have a handle on
a Page with a stale topOrigin. Then, when the web process communicates to the
NetworkProcess, the innocent web process is wrongfully terminated.
This resulted in ads on bbc.com to go blank after clicking on a few ads on the
page.
Here's the scenario that triggers the bug:
1. Page A is bbc.com (WP1) with a google.com iframe (WP2)
2. Some user click creates a new Page B in a different process (i.e. ad.com)
3. Event though there's no google.com iframe on Page B, it still has a copy of
Page B's state due to BrowsingContextGroup::addPage.
4. Page B's main frame navigates to ford.com (WP3). ford.com happens to have a
google.com iframe.
5. ford.com (WP3) sends BroadcastAllDocumentSyncData to the UIProcess to inform
it about the navigation.
5. Normally, WebPageProxy::broadcastAllDocumentSyncData will broadcast Page B's
new top origin information to other web process. However it has an early
return which skips this broadcast if the web process that sent
BroadcastAllDocumentSyncData doesn't match legacyMainFrameProcess. In this
scenario, the legacyMainFrameProcess still points to an old web process and
didn't get updated yet to the ford.com WP3.
6. WebKit sees that ford.com has a google.com iframe and places it in WP2 (which
was already hosting the google.com iframe on Page A).
6. Since WP2 never received the updated top origin, it has a stale view of Page
B and gets terminated for having the wrong top origin when talking to the
NetworkProcess.
This patch fixes this bug by keeping WP2's topOrigin for Page B in sync with the
actual main frame of page B.
The bug is that the right topOrigin doesn't get broadcasted if the sender is a
provisional page due to an early return in
WebPageProxy::broadcastAllDocumentSyncData.
Instead of dropping the broadcast, this patch updates top origin by updating
the DocumentSyncData of the web process's copy of WebPage
(during WebPage;:reinitializeWebPage).
This DocumentSyncData comes from the CreateWebPage IPC which is sent by
the UIProcess with the page's updated top origin.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::reinitializeWebPage):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::(SiteIsolation,
TopOriginInRemoteProcessesAfterMainFrameProcessSwap)):
Canonical link: https://commits.webkit.org/319465@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
