[webkit-changes] [WebKit/WebKit] 0e5830: REGRESSION (macOS Sonoma): Mouse clicks in Safari ...
Simon Fraser
noreply at github.com
Sat Sep 23 11:40:20 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0e58303d1704d1c10addc361f5b87270c9583854
https://github.com/WebKit/WebKit/commit/0e58303d1704d1c10addc361f5b87270c9583854
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-23 (Sat, 23 Sep 2023)
Changed paths:
M Source/WebCore/page/scrolling/ScrollingTree.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTree.serialization.in
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.cpp
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollingCoordinator.mm
Log Message:
-----------
REGRESSION (macOS Sonoma): Mouse clicks in Safari are sometimes vertically offset
https://bugs.webkit.org/show_bug.cgi?id=261992
rdar://113335852
Reviewed by Richard Robinson.
Some combinations of user scrolling and programmatic scrolling can result in a state where the UI
process and web process end up with different notions of scroll position. That causes hover and
clicks to be offset from where they should be.
This change does not address the fundamental cause of the bug, but does address one common case,
which is a programmatic scroll triggered by a content size change; this occurs on sites that toggle
a header banner between fixed and non-fixed based on scroll position.
There was already code in `ScrollView::updateScrollbars()` to prevent scroll position clamping due
to size adjustment when rubberbanding, but on macOS with UI-side compositing,
`isRubberBandInProgress()` would always return false.
The fix is to maintain RemoteScrollingCoordinator's set of nodes with active rubberbands on macOS
like we do on iOS, since `isRubberBandInProgress()` consults this set. We follow
"nodeWithActiveUserScroll" in `RemoteScrollingUIState`, having
`RemoteScrollingCoordinatorProxyMac::setRubberBandingInProgressForNode()` update this state, which
is pushed to the web process as needed.
I tried to make a test, but this behavior is very timing dependent, and I failed to make a test
that was reliable.
* Source/WebCore/page/scrolling/ScrollingTree.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTree.serialization.in:
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.cpp:
(WebKit::RemoteScrollingUIState::encode const):
(WebKit::RemoteScrollingUIState::decode):
(WebKit::RemoteScrollingUIState::reset):
(WebKit::RemoteScrollingUIState::addNodeWithActiveRubberband):
(WebKit::RemoteScrollingUIState::removeNodeWithActiveRubberband):
(WebKit::RemoteScrollingUIState::clearNodesWithActiveRubberband):
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.h:
(WebKit::RemoteScrollingUIState::nodesWithActiveRubberband const):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::setRubberBandingInProgressForNode):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
(WebKit::RemoteScrollingCoordinatorProxyMac::setRubberBandingInProgressForNode):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm:
(WebKit::RemoteScrollingTreeMac::setRubberBandingInProgressForNode):
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollingCoordinator.mm:
(WebKit::RemoteScrollingCoordinator::scrollingStateInUIProcessChanged):
Canonical link: https://commits.webkit.org/268363@main
More information about the webkit-changes
mailing list