me Reporter
	Description • 6 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36

Steps to reproduce:

Scroll upwards in a scroll container using a trackpad or another device which uses momentum scroll, and set scrollTop during a requestAnimationFrame. 


Actual results:

The scroll container's scrollTop is set, and all momentum scrolling is completely ended.


Expected results:

In other browsers, scrolling continues at the same momentum as it was before scrollTop was set. This is particularly valuable for creating a general occlusion solution, where only a few items are rendered at a time out of a much larger list of items for performance reasons.

When occluding, the sizes of unrendered items are not known before they are inserted into the DOM and actualized. Our strategy involves using placeholder elements which represent the estimated height of unrendered items, resulting in a mostly accurate scroll bar and scrolling behavior. However, as we scroll upwards and replace the placeholder with actual items, there are times when the item height may be different than we expected.

When this occurs, we use requestAnimationFrame to calculate the diff between what was expected and what the actual heights were, and seamlessly update the scroll position of the container. In all browsers except Firefox, this process is undetectable. With Firefox, the fact that setting scrollTop on the container also stops all momentum scrolling means that scroll will appear to jitter.

You can see a demo of this behavior, with jittering, here: https://html-next.github.io/vertical-collection/#/examples/flexible-layout

	Daniel Bodea [:danibodea]
	Comment 1 • 6 years ago

Hello,

Please help us with some more detailed steps to reproduce so we can confirm it. The technical knowledge needed to understand this issue is a bit high for me. Help me confirm it with a detailed list of steps to be followed in order to reproduce the issue.

Thank you for your contribution!

	me Reporter
	Comment 2 • 6 years ago

Demo of scrollTop setting differences between Firefox and other browsers. In this demo, whenever the user scrolls beyond 1000px, the scrollTop of the scroll container is reset to the top of the scroll container. In Firefox, this results in momentum scroll being cancelled, and all scrolling ending. In other browsers, momentum is maintained, giving a more seamless scroll effect.

	me Reporter
	Comment 3 • 6 years ago

The demo I've attached is about as minimal as I can make it. To reproduce, you essentially need to:

1. Add a scroll listener which sets scrollTop at some point for any reason
2. Scroll using a trackpad or another device that enables momentum scrolling

When the scroll listener triggers, on Firefox the new scroll position will be set and momentum scroll will be ended. In other browsers, this is not the case.

On mobile Firefox on iOS, a separate issue occurs. We believe this is a webkit bug due to the fact that all major iOS browsers use webkit, and all display the symptoms, so we've filed a bug report with them: https://bugs.webkit.org/show_bug.cgi?id=187449

We have not tested Firefox on other platforms at this time.

	Daniel Bodea [:danibodea]
	Comment 4 • 6 years ago

Hello,

I have reproduced the issue on MacBook Retina 2017 with v10.13.3 and any of the 3 main Firefox browsers (Nightly - v63.0a1, Beta - v62.0b7, Release - v61.0.1)

This the exact STR:
1. Open browser and reach "https://bug1474196.bmoattachments.org/attachment.cgi?id=8991396".
2. Scroll the page up using the trackpad.

Expected: The page cycles a few times through the page due to a scroll to top function at the bottom of the page.

Actual: The page is scrolled exactly one full round because the auto scroll function resets the position at the top.

Note: This issue does not occur on Chrome or Safari browsers.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 5 • 6 years ago

Layout or gfx issue.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 6 • 6 years ago

I believe fixing this requires fixing bug 1453425 first.

	ehonkulus
	Comment 7 • 6 years ago

What is priority p3? For my project this is very important to be fixed...

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 8 • 6 years ago

P3 means that we'll fix this, but don't know when.

	me Reporter
	Comment 9 • 6 years ago

It's worth noting that this behavior would be unnecessary for us to implement if Scroll Anchoring is accepted and implemented by the browsers https://drafts.csswg.org/css-scroll-anchoring/

Currently Chrome is the only browser that implements it, and it appears to have a buggy implementation.

	Botond Ballo [:botond]
	Comment 10 • 6 years ago

Yup, good point. Scroll Anchoring is also on our scrolling roadmap, tracked in bug 1305957.

I've added it as a dependency, but just to clarify, in this case either bug 1453425 _or_ bug 1305957 provides a path to solving this problem.

	Pulsebot
	Comment 13 • 5 years ago

Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/autoland/rev/a28a76c23e86
Don't change from PAN_MOMENTUM when we get a scroll offset update. r=botond
https://hg.mozilla.org/integration/autoland/rev/2b0f0d220a7c
Don't cancel fling animations when we receive a scroll update. r=botond