Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 870c656abd058a0c01d59d592813ad47029760c0
https://github.com/WebKit/WebKit/commit/870c656abd058a0c01d59d592813ad47029760c0
Author: Chris Dumez <[email protected]>
Date: 2026-06-10 (Wed, 10 Jun 2026)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/ProcessAssertionCocoa.mm
M Source/WebKit/UIProcess/ios/ProcessStateMonitor.h
M Source/WebKit/UIProcess/ios/ProcessStateMonitor.mm
Log Message:
-----------
[iOS] WKWebView stuck on a blank/white screen after a quick app-switch away
and back
https://bugs.webkit.org/show_bug.cgi?id=316741
rdar://176252756
Reviewed by Per Arne Vollan.
On iOS, ProcessStateMonitor proactively parks the WebContent (and GPU /
Networking) processes when RunningBoard signals that the app is about to be
suspended: processWillBeSuspendedImmediately() calls the handler that does
WebProcessPool::setProcessesShouldSuspend(true), which
calls
ProcessThrottler::setAllowsActivities(false) on every web process. While in
that state the page cannot take any foreground activity (foreground assertion,
"view is visible", runJavaScriptInFrameInScriptWorld, ...) and the drawing area
blanks the layer tree via hideContentUntilPendingUpdate().
The only paths that reset setProcessesShouldSuspend(false) were
ProcessStateMonitor::checkRemainingRunTime() observing that the runtime is no
longer limited -- which is driven by the *asynchronous* RBSProcessMonitor update
handler -- and the monitor being destroyed. The
UIApplicationWillEnterForegroundNotification handler in
WKProcessAssertionBackgroundTaskManager did not touch the ProcessStateMonitor at
all.
As a result, if the user flicks the app into the App Switcher and back to the
foreground before RunningBoard delivers its asynchronous "no longer
time-limited" state update, the web process is left with activities disallowed:
foreground activity requests keep getting
rejected, the blanked layer tree is
never replaced with a fresh commit, and the WKWebView is stuck showing a white
screen. This was confirmed in a device sysdiagnose where, on a fast
background->foreground bounce, the log showed setProcessesShouldSuspend(1) /
setAllowsActivities 0 followed by repeated "not allowed to add foreground
activity WebPageProxy::runJavaScriptInFrameInScriptWorld" and no subsequent
"Unhiding layer tree".
Fix this by letting the foreground transition reset the monitor synchronously
rather than relying solely on the late, asynchronous RunningBoard callback. When
the app enters the foreground we now call ProcessStateMonitor::
processDidBecomeRunning(), which resumes the web processes right away.
processDidBecomeRunning() early-returns when already in the Running state, so
the
call is idempotent with respect to the RBSProcessMonitor-driven reset.
* Source/WebKit/UIProcess/ios/ProcessStateMonitor.h:
Make processDidBecomeRunning() public so it can
be driven from the foreground
notification, mirroring the already-public processWillBeSuspendedImmediately().
* Source/WebKit/UIProcess/ios/ProcessStateMonitor.mm:
(WebKit::ProcessStateMonitor::processDidBecomeRunning): Add a release log on the
running transition for observability, consistent with the other state methods.
* Source/WebKit/UIProcess/Cocoa/ProcessAssertionCocoa.mm:
(-[WKProcessAssertionBackgroundTaskManager init]): On
UIApplicationWillEnterForegroundNotification, tell the ProcessStateMonitor that
the process is running again so suspended web processes resume immediately
instead of waiting on the asynchronous RunningBoard state update.
Canonical link:
https://flagged.apple.com:443/proxy?t2=Dd7K0V7DV7&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzE0OTYwQG1haW4=&emid=105db4fc-5426-42b7-9579-214199d0d8d7&c=11
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
