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