1704659 - Make overscroll snap-back animation feel more like Safari

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[Botond Ballo [:botond]]

This is a follow-up to bug 1702978. We made some changes to the physics of the overscroll snap-back animation in that bug with a view to making the animation feel more like Safari, but the discussion in that bug suggests additional changes are needed.

See in particular the video in bug 1702978 comment 10, and the descriptions in that comment and in bug 1702978 comment 12.

In addition, Martin played around with the feel of the animation provided the following feedback to me:

My impression is that our snapping is too harsh. When you are in an overscrolled state, and you release your fingers, we seem to go immediately from 0 to snap back speed. This makes it look like we yank/skip the first few frames. Safari is more smooth, maybe they are slower to accelerate, more like an S curve

It could also be something else: It feels like, when scrolling, the “snap back animation” starts from a different position than where I lifted my fingers. It feels like there is some momentum still applied which moves the page without animation to the final position, and then the snap back animation starts from there rather than from where I took my fingers off the trackpad

I’m convinced it’s related to this. Safari performs everything with an animation, and we seem to skip or accelerate parts of it for some reason. If I’m at the bottom of a page, and I do a fling, safari will overscroll, slow down, and the speed up in the other direction. Firefox seems to overscroll, then suddenly snap to some position and then speed up into the other direction. this sudden snap makes the effect feel yanky

Comment 1

[Botond Ballo [:botond]]

I wonder if, perhaps, Safari uses a different physics model than MSD (mass-spring-damper), and this is why we are having a difficult time making ours feel the same?

Comment 2

[Hiroyuki Ikezoe (:hiro)]

A difference I can think of from my observation is, when we initiate the snapback animation (OverscrollAnimation), we use the velocity at the moment.

If I leave my fingers from touchpad without moving them (i.e. no velocity), I feel Firefox's snapback is much smoother than Safari does. Presumably reducing this 1000 multiplier would mitigate the snappy animation?

Comment 3

[Markus Stange [:mstange]]

The 1000 multiplier is just a unit conversion (milliseconds to seconds).

It is possible that Safari isn't using MSD physics but it would surprise me.

One problem with our overscroll starting velocity is that the velocity doesn't take into account the "friction" that is applied to the scroll delta if scrolling is performed during overscroll. But I would have expected the "maximum velocity" clamping to mostly take care of that. But apparently that's not enough.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

FWIW, if I read correctly WebKit code, Safari uses this _NSElasticDeltaForTimeDelta which seems to be an internal function (in Cocoa).

Comment 5

[Timothy Nikkel (:tnikkel)]

It feels like we get a bit of discontinuity/extra small amount of acceleration that very quickly deteriorates when I lift my fingers from the touchpad.

Comment 6

[Botond Ballo [:botond]]

Attachment: graph.png

Following Timothy's suggestion, I graphed scroll position vs. time when a fast fling approaches the edge of the page.

The steep initial part of the graph, with the values above zero, is the fling approaching the edge of the page with high velocity.

The remainder of the graph, with the values below zero, is the overscroll animation. The first few frames are smooth, then there's a sharp discontinuity (==> this presumably is the problem), and then the rest of the animation is smooth.

Comment 7

[Timothy Nikkel (:tnikkel)]

Nice. That shows the problem much more clearly then I ever thought it would!

Comment 8

[Pascal Chevrel:pascalc]

Tracking for 89 as we will need to uplift.

Comment 9

[Botond Ballo [:botond]]

After playing around with this some more, I realized that I was mistaken about my description of the graph in comment 6: while I may have thought my fingers had left the touchpad before going into overscroll (it's hard to tell as it all happens within a very short time interval), they in fact remained on the touchpad for the first few frames of overscroll, and the discontinuity is the point where they left the touchpad.

The discontinuity in this case is due to the fact that while the the fingers are on the touchpad, the amount of overscrolling is determined by ApplyResistance(), while during the animation phase, it's determined by the animation's MSD physics. These are two separate calculations; I'm not sure if they were designed with a smooth transition from one to the other in mind.

Comment 10

[Botond Ballo [:botond]]

Attachment: graph-fling.png

Here's what the graph looks like in a scenario where my fingers have definitely left the touchpad before overscroll started. The visible discontinuity is no longer there.

It's not fully clear to me if this scenario is still problematic from a user experience point of view. Subjectively, this one feels fine to me.

Comment 11

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #9)

The discontinuity in this case is due to the fact that while the the fingers are on the touchpad, the amount of overscrolling is determined by ApplyResistance(), while during the animation phase, it's determined by the animation's MSD physics. These are two separate calculations; I'm not sure if they were designed with a smooth transition from one to the other in mind.

I think conceptually, the issue is that during the panning phase, the page only moves by a fraction of the amount of the event deltas (due to the ApplyResistance()), but it's the full deltas that we feed to the velocity tracker, which determines the starting velocity of the animation. The discontinuity is this jump from a lower actual velocity during the panning phase, to a significantly higher velocity at the start of the animation.

This suggests the following fix approach: during the panning phase, use the post-ApplyResistance() deltas for velocity computation.

Comment 12

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #11)

This suggests the following fix approach: during the panning phase, use the post-ApplyResistance() deltas for velocity computation.

I implemented this fix, it can be seen in this build (which is from this Try push).

Martin, Timea, would you be able to give it a try and see if it improves the issue of the animation being too snappy?

(Markus, Timothy, Hiro, you're welcome to give it a try on Mac as well and let me know what you think.)

Comment 13

[Botond Ballo [:botond]]

Attachment: Bug 1704659 - Compute pan gesture velocity based on the actual amount by which the page moved. r=hiro

In particular, when overscrolled, the velocity is now based on the
amount of overscroll after applying resistance.

Comment 14

[Martin Balfanz [:mbalfanz]]

Thank you Botond! This seems to fix the problem for me. I don't get into a "snappy" situation anymore and the animation remains smooth throughout. Love it!

The only case that I found that still feels off is when you do a very fast fling on Google's search result page. I don't think it has to do with the overscroll animation, but rather with the fixed header on the page.

Overall I'm super happy with the result and think that it will fix this bug!

Comment 15

[Timea Cernea [:tbabos][inactive]]

Thanks for this fix Botond! I can also confirm that this fix improved greatly the overscroll feel. Did a quick comparison again with Safari and here are the following observations:

1. The animation is no longer snappy
2. For short swipe gesture - at the top or the bottom of the page - our overscroll length is shorter compared to Safari (I personally agree with this one)
3. For long swipe gestures - when we hit the bottom or the top of the page - similar behavior as Safari, quick and long overscroll animation

If there is anything we could maybe improve at some point, that would be to slow down a bit the long overscroll animation that we hit at point 3. However, this patch did wonders and should be uplifted to make it in FX89.

Here is a new comparison recording for a better view: https://drive.google.com/file/d/1cdasw9sot_8zLRkdL0PmPY7TOBgk-LPH/view?usp=sharing

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e3f81c027cbf
Compute pan gesture velocity based on the actual amount by which the page moved. r=hiro

Comment 17

[Martin Balfanz [:mbalfanz]]

Thank you for the feedback, Timea. I think it would make sense to move the enhancement you described to a separate bug. This one here was considered release-blocking for the feature, and I think with the latest patch we are in great shape already.

Comment 18

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/e3f81c027cbf

Comment 19

[Botond Ballo [:botond]]

Comment on attachment 9218533 [details]
Bug 1704659 - Compute pan gesture velocity based on the actual amount by which the page moved. r=hiro

Beta/Release Uplift Approval Request

• User impact if declined: [Needed for MR1 / Proton] When scrolling to an edge of the page, users may experience on overscroll animation that feels unnatural (the transition when they lift their finger from the touchpad is not smooth)
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a targeted change, and only affects the physics of the overscroll animation (enabled by default on Mac only)
• String changes made/needed:

Comment 20

[Pascal Chevrel:pascalc]

Comment on attachment 9218533 [details]
Bug 1704659 - Compute pan gesture velocity based on the actual amount by which the page moved. r=hiro

Approved for 89 beta 6, thanks.

Comment 21

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/f041f7319128

Comment 22

[Timea Cernea [:tbabos][inactive]]

NI? myself for QA Uplift verification and regression testing.

Comment 23

[Timea Cernea [:tbabos][inactive]]

Verified-fixed on latest Firefox Nightly 90.0a1 (2021-04-26) (64-bit) and Beta 89.0b8 with the same results as in Comment 15.