Closed Bug 1474196 Opened Last year Closed 9 months ago

Setting scrollTop stops momentum scroll

Categories

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

61 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla66
Tracking Status
firefox65 --- wontfix
firefox66 --- verified
firefox67 --- verified

People

(Reporter: me, Assigned: rhunt)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Attachments

(3 files)

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
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!
Flags: needinfo?(me)
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.
Flags: needinfo?(me)
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.
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.
Status: UNCONFIRMED → NEW
Component: Untriaged → Document Navigation
Ever confirmed: true
Product: Firefox → Core
Layout or gfx issue.
Component: Document Navigation → Layout
I believe fixing this requires fixing bug 1453425 first.
Component: Layout → Panning and Zooming
Depends on: 1453425
Priority: -- → P3
Whiteboard: [gfx-noted]
What is priority p3? For my project this is very important to be fixed...
P3 means that we'll fix this, but don't know when.
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.
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.
Depends on: 1305957
Assignee: nobody → rhunt
See Also: → 1520666

A fling animation is computed using velocity and so it can continue
with a relative or absolute scroll update. This seems to match other
browser's behavior.

Attachment #9037684 - Attachment description: Bug 1474196 - Don't cancel fling animations or change from PAN_MOMENTUM when we get a scroll offset update. r?botond → Bug 1474196 - Don't change from PAN_MOMENTUM when we get a scroll offset update. r?botond
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
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

I have verified this fix on MacBook Pro 2017 with OS 10.13.6.
This issue is now fixed on Nightly v67.0a1 from 20190128, and it still occurs on Beta v65.0 RC and Release v64.0.3.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.