Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 06919bc1ebe415ba055151c815f8b94680d5fd3c
https://github.com/WebKit/WebKit/commit/06919bc1ebe415ba055151c815f8b94680d5fd3c
Author: Carlos Alberto Lopez Perez <[email protected]>
Date: 2026-07-27 (Mon, 27 Jul 2026)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/gtk/TestExpectations
M Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp
Log Message:
-----------
Cherry-pick 317769@main (cfde6a8041f4).
https://bugs.webkit.org/show_bug.cgi?id=319949
REGRESSION(317427@main): [GLIB] Wheel events crash with an assertion in
EventDispatcher::dispatchWheelEvent
https://bugs.webkit.org/show_bug.cgi?id=319949
Reviewed by Charlie Wolfe.
A wheel event is usually handled across several threads: a background thread
receives it, a scrolling thread can do the scroll on its own to keep
scrolling
smooth, and the main thread runs the page JavaScript wheel listeners.
Since 317427@main the "was the event handled" answer is returned as an async
reply to the WheelEvent message via a CompletionHandler instead of as a
separate DidReceiveEventIPC message.
And every CompletionHandler asserts that it is executed on the thread where
it was created (unless specified otherwise via the AnyThread parameter).
The main reply handler (the one carrying the answer back to the UIProcess)
is already correctly created as AnyThread, because depending on the path
it gets called either from the scrolling thread or from the main thread.
The problem is in the passive scrolling path, there the reply is sent from
the scrolling thread as soon as the scrolling is done without waiting for
the main thread ACK, but the event still has to be forwarded to the main
thread after completed so the passive DOM listeners run.
The result of forwarding this to the main thread is not used because the
main reply handler already finished, so a no-op CompletionHandler is passed,
which is created on the scrolling thread but executed on the main thread,
therefore the assertion hits.
The fix is to simply mark this no-op CompletionHandler as AnyThread.
This is not a problem on the Mac port because it runs the scrolling thread
in the UIProcess and doesn't exercise this codepath, however in the GTK
and WPE case the scrolling thread runs in the WebProcess and wheel events
are routed through this EventDispatcher.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/gtk/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebKit/WebProcess/WebPage/EventDispatcher.cpp:
(WebKit::EventDispatcher::internalWheelEvent):
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
