← WebKit — 2026-W39
3d5f53ae29749019158dd9c055f16c73547f3a36 [Site Isolation] Mouse events should not be affected by a unresponsive iframe process
severity medium
class Race
confidence 0.4
signal score 10.34
Source/WebKit/UIProcess
Primitive: mouse-event queue stuck forever when a subframe process hangs/crashes or replies for a retired event
Triage note: Adds remoteFrameMouseEventTimeoutTimer and connection-gone handling so an unresponsive/crashed subframe process no longer wedges the mouseEventQueue, and compares the retained sentEvent pointer to ignore replies for already-retired events. Liveness/DoS robustness fix for site-isolated input handling; not a memory-safety primitive.
Triage note: Adds remoteFrameMouseEventTimeoutTimer and connection-gone handling so an unresponsive/crashed subframe process no longer wedges the mouseEventQueue, and compares the retained sentEvent pointer to ignore replies for already-retired events. Liveness/DoS robustness fix for site-isolated input handling; not a memory-safety primitive.
Structural signals: smartptr_member_added (+3.0), null_guard (+2.59), uaf_lifetime (+4.75)
Commit message
[Site Isolation] Mouse events should not be affected by a unresponsive iframe process
https://bugs.webkit.org/show_bug.cgi?id=324938
rdar://129038359
Reviewed by Charlie Wolfe.
WebPageProxy has a single mouse event queue for the page and only sends the next event once the
current one has been replied to. When the main frame forwards an event to an iframe in another
process, the queue could get stuck forever, blocking mouse events for every frame in the page:
1. The iframe process hangs and never replies. Mouse moves don't even start the responsiveness timer.
2. The iframe process goes away (e.g. it was terminated for being unresponsive). The reply is
cancelled with a null connection, and we returned without retiring the event. The queue was
only cleared when the main frame's process exited.
3. The target frame no longer exists when the event is forwarded, so nothing was sent and the
event was never retired.
Fix these by retiring the event as unhandled when the reply is cancelled or the target frame is
gone, and by adding a timeout for events forwarded to a subframe process. Also make the reply
handler ignore replies for events that are no longer at the front of the queue so that a late or
cancelled reply can't retire a newer event.
Tests: TestWebKitAPI.SiteIsolation.MouseEventsAfterHoveringOverUnresponsiveSubframe
TestWebKitAPI.SiteIsolation.MouseEventsAfterUnresponsiveSubframeProcessIsTerminated
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::Internals::Internals):
(WebKit::WebPageProxy::sendMouseEvent):
(WebKit::WebPageProxy::resetStateAfterProcessExited):
(WebKit::WebPageProxy::mouseEventHandlingCompleted):
(WebKit::WebPageProxy::remoteFrameMouseEventTimedOut):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebPageProxyInternals.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::waitForMainFrameMouseDown):
(TestWebKitAPI::TEST(SiteIsolation, MouseEventsAfterHoveringOverUnresponsiveSubframe)):
(TestWebKitAPI::TEST(SiteIsolation, MouseEventsAfterUnresponsiveSubframeProcessIsTerminated)):
Canonical link: https://commits.webkit.org/321792@main
Before / after
Loading diff…
On This Page