Affected Versions:
Nightly 89.0a1

Tested On:
MacOS 10.14, 10.15, M1 Macbook Big Sur

Steps to Reproduce:

1. Go to any sites that is scrollable, ex: facebook news feed, reddit, etc
2. Reach the top or the bottom of the page
3. Scroll up or down using fast swipe gesture on the trackpad or magic mouse

Expected Results:
The overscroll effect should be smooth and have a natural rubber-like feeling.

Actual Result:
The overscroll effect seems to be snappy for fast swipe gestures.
Comparisons were also made with Chrome and Safari which have a smooth overscroll animation regardless of the swipe speed. On Firefox the blank space created for the animation might also be too large, hence the snappy feeling is intensified.

Please see attached recordings for reference.
Comparison with Chrome: https://streamable.com/04gmms
Facebook example: https://streamable.com/kdncc0

Severity:
Marked it with S2 since the natural feel is not quite optimal right now. Feel free to change it if you consider otherwise.

Does this happen with a single fast swipe gesture, or does it require multiple fast swipes (where the velocity "stacks up")?

Depends on D110843

This makes it so that quick flings don't create such a large initial overscroll gap.

Before: https://share.firefox.dev/3fFP5Kp
After: https://share.firefox.dev/3fHA4b1

The "before" profile shows a jump from -65 to -320 in the overscroll amount, when
the animation is started, and the "after" profile shows a jump from -57 to -201.

Depends on D110844

This makes the snapback less aggressive, and feels more like Safari to me.
Reducing the stiffness makes the animation take longer to complete.
To counteract the longer time, I've also reduced the damping a little bit;
reducing the damping makes the animation complete a little more quickly.

Depends on D110845

It is more visible with multiple fast swipes but can also be observed with a single fast swipe. I can't really reproduce this with slow single or multiple swipes.

https://hg.mozilla.org/mozilla-central/rev/45fc0c521ac9
https://hg.mozilla.org/mozilla-central/rev/45e0b8b27b24
https://hg.mozilla.org/mozilla-central/rev/6c32893495f9
https://hg.mozilla.org/mozilla-central/rev/f1e31c8bcec0

Timea, can you check whether these patches resulted in the experience you expected? If not, we now have new prefs apz.overscroll.max_velocity, apz.overscroll.spring_stiffness, and apz.overscroll.damping that can be used to find better default values.

Hi Markus,

We tested on Nightly with the patch landed on 2 different macOS devices but we still see the same snap effect. We also tried to change the pref values you mentioned and experimented with different combinations but couldn't find the ideal version that could at least match Safari's behaviour.

Our overall speculation is that the returning animation (not sure how to call this out technically, snapback?) upon reaching the end of the scroll event is too sudden/fast and causes the "snappy" effect instead of an elastic feeling. Here is a new recording that compares it with Safari: https://drive.google.com/file/d/1U5eLDRvbX-G5KnscdT8Toa35K65cU97N/view?usp=sharing. Reducing the apz.overscroll.spring_stiffness to values under 200 did not eliminate that feel (we also tried the other prefs with different values)

Not sure if we could help more here and unfortunately we can't proceed further with QA Nightly testing for this feature like this. Let me know if there is anything else we could try out.

(In reply to Timea Cernea [:tbabos] from comment #10)

unfortunately we can't proceed further with QA Nightly testing for this feature like this.

We can try further to make the snap-back feel more like Safari. However, could you elaborate on why this is a blocker for further testing?

It seems to me that several other aspects of the feature are orthogonal (i.e. can be tested independently) of the physics of the snap-back animation, for example:

• whether the overscroll ever gets stuck in any scenario (shouldn't happen)
• interactions between horizontal and vertical axes
• interacting with the page (e.g. click) while overscrolled

Hi Botond,

Our main concern was that testing before this issue is fixed, as well as Bug 1700215, would jeopardize our testing results given both of the issues are basically how the elastic overscroll works (and feels) and that would fail the majority of our testcases. One of the main and high-priority scopes for this feature was the natural feel, hence the reason for halting testing was anchored to that.

However, we re-analyzed this matter and decided we could isolate both issues to specific testcases and test around them for the other aspects which you also mentioned. Please note that the Nightly report quality status color will not overlook the mentioned issues but we will focus on other aspects in order to find other unrelated bugs as soon as possible.

Apologies that the previous comment and sudden decision to halt testing were not discussed thoroughly before and raised unanswered questions and concerns. Time was short given we were also pressured by the Nightly 89 Report deadline which is today (9th April). We continued testing today as described above and we will provide a report on Monday - EOD.

Thanks, Timea!

As some patches have landed here, let's track additional changes in a follow-up. I filed bug 1704659 for this purpose.

Marking this as verified-fixed given additional changes and adjustments will be made in Bug 1704659.