[webkit-changes] [WebKit/WebKit] e7ab50: [macOS] If you scroll the page without moving the ...

[Simon Fraser]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e7ab50a7e7be8981e4a7992320befbd8b61175f2
      https://github.com/WebKit/WebKit/commit/e7ab50a7e7be8981e4a7992320befbd8b61175f2
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2024-05-02 (Thu, 02 May 2024)

  Changed paths:
    M Source/WebCore/PAL/pal/HysteresisActivity.h
    M Source/WebCore/page/EventHandler.cpp
    M Source/WebCore/page/EventHandler.h
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Source/WebKit/WebProcess/WebPage/WebPage.h
    M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
    M Tools/TestWebKitAPI/Tests/WebCore/HysteresisActivityTests.cpp

  Log Message:
  -----------
  [macOS] If you scroll the page without moving the mouse, we fail to update the cursor as things scroll underneath it
https://bugs.webkit.org/show_bug.cgi?id=273335
rdar://122347347

Reviewed by Tim Horton.

If you don't move the mouse after loading a page, we'll never update the cursor after scrolling via the trackpad.
This is because the web process never gets an updated mouse position if the only events we handle are wheel
events, which are handled entirely in the UI process (in the absence of JS wheel event handlers).

Fix by explicitly sending `setLastKnownMousePosition()` to EventHandler when we know that we're not
going to send the wheel events to the web process. Only do this on the `began` event, since we don't want to
flood the web process with new IPC when the position doesn't change (wheel gestures usually keep the same
position throughout).

Even when we did send wheel events to the web process, they would fail to update the last known mouse position,
so fix that in `EventHandler::handleWheelEventInternal()`.

I tried to write a test, but it was impossible to make it not flakey (it's attached to the radar).
However, the test revealed a race condition; the reload raced with the WebPage::m_pageScrolledHysteresis timer,
and sometimes this would cause `WebPage::pageDidScroll()` to get called right after we've constructed the new
ScrollView with a zero scroll position, which would get saved to the history item, and clobber the previously
saved scroll offset; this caused the scroll offset to get reset on reload. Fix by having `WebPage::didCommitLoad()`
call `cancel()` `m_pageScrolledHysteresis`, which needs to implemented in HysteresisActivity, with a test.

* Source/WebCore/PAL/pal/HysteresisActivity.h:
(PAL::HysteresisActivity::cancel):
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::handleMousePressEvent):
(WebCore::EventHandler::handleMouseDoubleClickEvent):
(WebCore::EventHandler::handleMouseMoveEvent):
(WebCore::EventHandler::handleMouseReleaseEvent):
(WebCore::EventHandler::handleMouseForceEvent):
(WebCore::EventHandler::handleWheelEventInternal):
(WebCore::EventHandler::setLastKnownMousePosition):
* Source/WebCore/page/EventHandler.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::continueWheelEventHandling):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::setLastKnownMousePosition):
(WebKit::WebPage::didCommitLoad):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebCore/HysteresisActivityTests.cpp:
(TestWebKitAPI::TEST(HysteresisActivity, Cancelation)):

Canonical link: https://commits.webkit.org/278297@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications