Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: bdb0943f393055ad79b1a8cd7ba04515f82a7768
https://github.com/WebKit/WebKit/commit/bdb0943f393055ad79b1a8cd7ba04515f82a7768
Author: Simon Fraser <[email protected]>
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@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@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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes