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