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

Reply via email to