Bug 1922904 - Fix bug 1780701 in a different approach. r=botond
In bug 1780701, we changed ScrollSnapUtils::GetSnapPointForDestination not to return a valid SnapDestination if the snap position is equal to the original scroll destination. But it has a bad side-effect on wheel scrolling. While wheel scrolling, there are multiple wheel inputs comming from OS, in every wheel input we do use the destination of the animation running at that moment [1]. So if in the first wheel input we created a smooth animation for snapping to the SnapDestination, and then in the second wheel input GetSnapPointForDestination doesn't return any valid SnapDestination so that the smooth animation is clobbered [2]. To avoid this bad side-effect, we do skip scroll snapping in the call site, ScrollContainerFrame::ScrollSnap, if the snap position equals to the original scroll destination. [1] https://searchfox.org/mozilla-central/rev/53e8dfd81c32f1ab275516406ec06a68136aaef0/gfx/layers/apz/src/AsyncPanZoomController.cpp#2585-2586 [2] https://searchfox.org/mozilla-central/rev/53e8dfd81c32f1ab275516406ec06a68136aaef0/gfx/layers/apz/src/AsyncPanZoomController.cpp#2603 Differential Revision: https://phabricator.services.mozilla.com/D227409
This commit is contained in:
@@ -5024,6 +5024,13 @@ void ScrollContainerFrame::ScrollSnap(const nsPoint& aDestination,
|
||||
// site using `GetScrollPosition()` as |aStartPos|.
|
||||
if (auto snapDestination = GetSnapPointForDestination(
|
||||
ScrollUnit::DEVICE_PIXELS, snapFlags, pos, destination)) {
|
||||
// Bail out if there's no scroll position change to do a workaround for bug
|
||||
// 1665932 (even if the __layout__ scroll position is unchanged, the
|
||||
// corresponding scroll offset update will change the __visual__ scroll
|
||||
// offset in APZ).
|
||||
if (snapDestination->mPosition == destination) {
|
||||
return;
|
||||
}
|
||||
destination = snapDestination->mPosition;
|
||||
ScrollToWithOrigin(
|
||||
destination, nullptr /* range */,
|
||||
|
||||
Reference in New Issue
Block a user