[webkit-changes] [WebKit/WebKit] bdb094: REGRESSION (263995 at main): preventDefault on wheel ...
Simon Fraser
noreply at github.com
Wed Jul 5 14:25:12 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: bdb0943f393055ad79b1a8cd7ba04515f82a7768
https://github.com/WebKit/WebKit/commit/bdb0943f393055ad79b1a8cd7ba04515f82a7768
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-07-05 (Wed, 05 Jul 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
REGRESSION (263995 at main): preventDefault on wheel events can still result in page scrolling (fast/scrolling/mac/event-region-prevent-default-with-sublayer.html is a consistent failure)
https://bugs.webkit.org/show_bug.cgi?id=258741
rdar://111420041
Reviewed by Tim Horton.
263995 at main broke the "only the first wheel event should be cancelable" logic such that if the page
called preventDefault() on a wheel event, we'd always time out the `m_waitingForBeganEventCondition`
condition, which results in us making a wheel event sequence that should be synchronous (i.e. page
can consume all events) into an async one (which can trigger scrolling).
This manifested as page scrolls in fast/scrolling/mac/event-region-prevent-default-with-sublayer.html.
There are two aspects to the fix. First, when we get back to `WebPageProxy::handleWheelEventReply()`
in the UI process with no nodeID (which means that the web process didn't use the event for main
thread scrolling for any node), we still call into the scrolling coordinator which calls into
`RemoteLayerTreeEventDispatcher::wheelEventHandlingCompleted()`. This flow eventually early
returns from `RemoteScrollingTreeMac::handleWheelEventAfterDefaultHandling()` if the nodeID is zero,
but this ensures that we always end up hitting WebPageProxy::wheelEventHandlingCompleted() which
is necessary.
Second, pull the code that notifies the m_waitingForBeganEventCondition into its own function that
is called on the main thread (previously we tried to notify the condition on the scrolling thread,
which was the waiting thread, which is why it always timed out).
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h:
(WebKit::RemoteScrollingTree::receivedEventAfterDefaultHandling):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteLayerTreeEventDispatcher.cpp:
(WebKit::RemoteLayerTreeEventDispatcher::wheelEventHandlingCompleted):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm:
(WebKit::RemoteScrollingTreeMac::receivedEventAfterDefaultHandling):
(WebKit::RemoteScrollingTreeMac::handleWheelEventAfterDefaultHandling):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::handleWheelEventReply):
Canonical link: https://commits.webkit.org/265781@main
More information about the webkit-changes
mailing list