Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f5b7a0e8ef5d9a43f004d4c9db666408be234302
https://github.com/WebKit/WebKit/commit/f5b7a0e8ef5d9a43f004d4c9db666408be234302
Author: Ben Nham <[email protected]>
Date: 2026-08-07 (Fri, 07 Aug 2026)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm
M Source/WebKit/UIProcess/RemotePageProxy.cpp
M Source/WebKit/UIProcess/SuspendedPageProxy.cpp
M Source/WebKit/UIProcess/SuspendedPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
Site-isolated iframe processes keep a page load assertion after a cross-site
navigation
https://bugs.webkit.org/show_bug.cgi?id=320790
rdar://183676310
Reviewed by Per Arne Vollan.
We are seeing that remote frame processes are running too long after a main
frame navigation due to
the remote frame processes holding a page load activity through a navigation
(m_networkActivity in
WebProcessActivityState).
The reason for this is that when a PSON occurs, we try to move the page load
activities from the old
WebProcesses pre-swap to the new WebProcesses post-swap via
NavigationState::didSwapWebProcesses()
=> WebPageProxy::takeNetworkActivity().
This works for the main frame because WebPageProxy's
m_mainFrameProcessActivityState stays the same
through the navigation.
It doesn't work for remote frames because a PSON will generally cause a
BrowsingContextGroup
switch. So by the time WebPageProxy::takeNetworkActivity() runs, its BCG points
to a new set of
RemotePageProxy objects. WebPageProxy has no way of reaching back to the old
BCG pre-swap, so it
also can't reach the pre-swap RemotePageProxy objects. So the page load
activities associated with
those old RemotePageProxy objects keep running until the RemotePageProxy dies.
This becomes a problem when multi-process back/forward cache is enabled,
because that can keep a
RemotePageProxy object alive for a long time (as long as it's in cache).
Previously, this wasn't
really an issue because RemotePageProxy objects would die soon after the PSON.
My first attempt at fixing this (318458@main) was extremely simple: I just
reset m_networkActivity
inside WebProcessActivityState::reset. However, while this works to fix this
bug, it caused a large
PLT regression through another convoluted chain of events:
1. The network activity might be the last activity for the process, causing it
to suspend.
2. WebProcess::prepareToSuspend runs and thinks the process isn't in the
process cache, so it dumps
all caches (see 289156@main).
3. We then shortly thereafter put this process in the process cache with cold
caches, which leads to
a PLT regression.
So this is my second attempt at fixing the issue. Instead of preemptively
dropping the network
activity in WebProcessActivityState::reset, we now drop the network activity
when the
RemotePageProxy enters the b/f cache (in SuspendedPageProxy::startSuspension).
This really should be cleaned up at some point, but I can't see a cleaner way
of doing this without
a major refactor.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivateForTesting.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm:
(+[WKWebView _suspendedRemotePageNetworkActivityCountForTesting]):
* Source/WebKit/UIProcess/RemotePageProxy.cpp:
(WebKit::RemotePageProxy::processDidTerminate):
* Source/WebKit/UIProcess/SuspendedPageProxy.cpp:
(WebKit::SuspendedPageProxy::remotePagesWithNetworkActivityCountForTesting):
(WebKit::SuspendedPageProxy::startSuspension):
(WebKit::SuspendedPageProxy::dropNetworkActivityOnRemotePages):
* Source/WebKit/UIProcess/SuspendedPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::(SiteIsolation,
SharedProcessDropsPageLoadActivityAfterCrossSiteNavigation)):
Canonical link: https://commits.webkit.org/318796@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
