1916760 - scripted smooth-scroll physics differ between Firefox vs. Chrome (particularly at the start of a JS-initiated scroll operation, where Firefox's immediate rapid velocity may be disorienting)

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

[Spinning this off from bug 1910608 to capture a behavior-difference in smooth scrolling.]

STR:

1. Load attached testcase.
2. Click "scroll to bottom" button, and pay attention to how the speed changes over the duration of the scroll operation.

FIREFOX RESULTS:
The scroll operation starts out at top-speed (no acceleration period that I can perceive), with some slowdown/deceleration at the end.

CHROME RESULTS:
The scroll operation starts out slow, accelerates to a top-speed in the middle, and then decelerates at the end.

The difference might kind of be a question of taste; but it does seem like maybe the Firefox behavior is a little harder to follow, since our initial burst feels like a "teleport"/jump -- it's hard to track where the content-that-you-were-looking-at ends up, perhaps? Whereas with the Chrome behavior, you can see the original content smoothly scroll out of view. (In both cases you can see the final content smoothly animating into view.)

(I'm not sure we want/need to take any action here; I just wanted to be sure we had a bug to capture the specific difference that was observed in bug 1910608.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of Firefox behavior

Here's a screencast, captured on 131.0a1 (2024-08-30) (64-bit) on Ubuntu 24.04

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of Chrome behavior

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

[reposting testcase 1 with a <meta name="viewport"...> tag for easier viewing on mobile]

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screencast of Firefox behavior on Android

I'm attaching two screencasts from Android now, which show the same difference as on desktop (Firefox has an immediate burst of speed vs. Chrome has a "slow start"). The difference might be a bit easier to see in these ones, since I think they're captured with a higher framerate.

Here's the first Android screencast, with Firefox-for-Android behavior.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast of Chrome behavior on Android

Here's Chrome's behavior on Android. The "slow start, acceleration to be fast in the middle, slow end" behavior is fairly easy to see here.

Comment 6

[Daniel Holbert [:dholbert]]

This is a bit more noticeable-as-being-a-bug in bug 1912406, I think -- over there, Amazon Prime Video has a carousel that periodically scrolls on its own, using smooth-scroll actions.

In Firefox, these periodic scroll events are a bit harder to visually track, since we go from being perfectly-still to scrolling-at-top-speed without any user interaction. So if the user is e.g. trying to read something on the previously-visible-part-of-the-carousel, that piece of content will suddenly disappear out from under them without warning. Arguably the Chrome behavior of slow-start-with-gradual-acceleration works better for this sort of use-case.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (dynamic)

Here's a testcase to emulate the Prime Video carousel, with a carousel that advances on its own.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screencast of Firefox behavior on Android with testcase 2

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screencast of chrome behavior on Android with testcase 2

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: side-by-side comparison of screencasts on testcase 2 (Firefox on left, Chrome on right), at 10% playback speed

Comment 11

[Daniel Holbert [:dholbert]]

Looking in the just-attached comparison video, focusing just on the start of the smooth-scroll animation, you can see that Firefox starts out moving at full-speed, whereas Chrome has some "ramp up" time.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I suppose this difference comes from the fact that we've used MSD physics, thus the initial scroll distance is large. CCing Markus.

FWIW, there are two prefs layout.css.scroll-behavior.damping-ratio and layout.css.scroll-behavior.spring-constant to control the MSD physics for JS smooth scrolling.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #12)

I suppose this difference comes from the fact that we've used MSD physics, thus the initial scroll distance is large. CCing Markus.

Indeed, I think so.

FWIW, there are two prefs layout.css.scroll-behavior.damping-ratio and layout.css.scroll-behavior.spring-constant to control the MSD physics for JS smooth scrolling.

Thanks. From poking and setting extreme values:

• the damping-ratio pref seems to control a "wobble" at the end of the animation (e.g. I can get an extremely silly "wobble" if I set it to 0.2 :) )
• the spring-constant pref seems to control the overall speed (so e.g. layout.css.scroll-behavior.spring-constant = 30 makes the scroll happen more slowly such that I can see it happen). However, it also makes the whole scroll operation take much longer. (And I think the initial velocity might still be the highest velocity?)

In cases where the scroll is initiated by a user action, our model makes intuitive sense to me (it feels like the user action -- e.g. a button-press -- is intuitively serving as a "hammer-strike" or a "fling" to grant an instant burst of speed, from which the content then progressively slows down -- that's my perception of how MSD physics is operating here at least). But in cases like the Prime Video carousel where the scroll is happening on its own without any user interaction, this instant burst of speed arguably feels a bit disconcerting, and a Bezier model feels maybe-preferable, so that things are moving slowly (granting the user the ability to reason about the context) at the start and end of the out-of-nowhere smooth-scroll operation.

Comment 14

[Markus Stange [:mstange]]

The MSD-based implementation was expected to be somewhat more aggressive about accelerating, but it does appear to be too aggressive in this case. And unfortunately we can't separately control "how quickly do we accelerate at the beginning" and "how quickly do we slow down near the end" with a single spring stiffness constant.

The best way forward may be to go back to the bezier-based animation, and do what Chrome did to make it feel more "Windows native" on Windows: Lengthen the duration of the animation based on the total distance.

Comment 15

[Markus Stange [:mstange]]

Sorry, my previous comment was based on an in correct assumption - I forgot that we have two implementations of MSD-based scroll animations!
This bug is about the animation that's used for scroll-behavior: smooth.
My comment 14 was about the animation that's used for wheel scrolling when the pref general.smoothScroll.msdPhysics.enabled is set.
Those are different things!

I don't really have a strong opinion on what to do with the animation that's used for scroll-behavior:smooth. But I think it would make sense to make it use the same "smooth scrolling" animation as we use for wheel scrolling - bezier-based or MSD depending on the value of the general.smoothScroll.msdPhysics.enabled pref. But I don't know if that would actually fix this bug.

As for scroll snapping, we should keep using MSD-based animations for scroll snapping.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

We will discuss this in an APZ panning meeting.