1710246 - [Overscroll] Rubberbanding Snapback gets shorter when you repeat it into the same direction

Status: NEW

(Core :: Panning and Zooming, enhancement)

Description

[Mehmet]

Attachment: Nightly_vs_Safari.mov

Nightly 90.0a1 (2021-05-08) (64-Bit)
macOS 11.3.1

1.) Open Nightly and Safari (or an another macOS application) side by side
2.) Visit e.g. mozilla.org in both applications
3.) Compare the rubberbanding snapbacks in both application

Actual: When you repeat the overscroll rubberbanding to the same direction, then Nightly's Snapback doesn't match exactly Safari's Snapback. It becomes then shorter than Safari's. This only happens when you repeat the overscroll rubberbanding into the same direction. With the first overscroll rubberbanding the snapback seems to match with Safari.

Expected: When you repeat rubberbanding into the same direction, the snapback should not get shorter.

A screencast is attached.

Comment 1

[Mehmet]

Adding overscroll blockers: bug 1124108, bug 1605234, bug 1697681

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Mehmet, thanks for reporting.

Unfortunately I can't play back the recording on my Linux box (on Mac either). Can you please attach it with a different code?
(also please do not block overscroll-release on your own decisions, we've been managing the bug for the next release Firefox 89)

Comment 3

[Mehmet]

Attachment: Nightly_vs_Safari.webm

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

Mehmet, thanks for reporting.

Unfortunately I can't play back the recording on my Linux box (on Mac either). Can you please attach it with a different code?
(also please do not block overscroll-release on your own decisions, we've been managing the bug for the next release Firefox 89)

Hi Hiroyuki, sorry for adding the blocker. My mistake :(

I converted the Quicktime-Movie to Webm. Please find it attached. I hope, it is this time playable for you. Thanks :)

Comment 4

[Botond Ballo [:botond]]

The difference here is (1) an overscroll at the end of regular momentum scrolling of the page contents vs. (2) an overscroll starting from a stationary position. In the first case, the velocity incoming to the overscroll animation is larger, as it's computed based on the faster movement during the regular momentum scrolling. In the second case, the velocity comes from panning into overscroll which results in slower movement due to the "resistance" applied during overscroll, and thus a slower velocity.

Making the velocity computation take into account the resistance was a change made in bug 1704659, which was considered a high priority by QA due to the overscroll animation previously feeling too "snappy".

It's worth noting as well that in QA's feedback on that bug, in bug 1704659 comment 15, they suggested that if we make further changes, they should be in the direction of slowing the momentum case down, rather than speeding the stationary case up.

At the end of the day, while we have tried (and will continue to try) to make the animation feel pleasant and behave similar to Safari, I don't think that making it behave identical to Safari is a realistic goal, given that they are after all separate pieces of software implemented by separate pieces of code.

Comment 5

[Botond Ballo [:botond]]

Just wanted to add that in principle I'm open to either of the "slow the momentum case down" or "speed the stationary case up" approaches, but it's not obvious to me how to accomplish either of those without re-introducing the discontinuity ("snappiness") that was at issue in bug 1702978 / bug 1704659.

Comment 6

[Mehmet]

Hi Botond, if you think the actual behavior is fine and it is not worth to put more energy into it, then please feel free to close this report. I am probably the only user who noticed the different behavior. We are already more than happy, that Rubberbanding found finally its way to Firefox on Mac :)

Comment 7

[Martin Balfanz [:mbalfanz]]

I'm marking this as an enhancement as I don't think there's something inherently wrong with our current approach. I also agree that, while Safari serves as primary reference, it's not our goal to match the exact same behavior. But it's good to keep this on file as we further enhance the feature.