Skip to content

scrollToIndex with align: end gets "stuck" after scrolling to top #473

@robinzigmond

Description

@robinzigmond

Describe the bug

When using scrollToIndex with dynamically-sized elements and { align: "end" }, scrolling to an element at or close to the top of the scroll area causes the scroll to be "locked" to the index - as the user tries to scroll away, it keeps jumping back.

Note: the bug seems very similar to #467 which was fixed in version beta.36 - however the undesired behaviour still occurs in the circumstances described above (and the sandbox is a very minimal adaptation of the working one in the docs - all I have changed is adding the "scroll to top" button and added {align: "end"} to the scrollToIndex calls).

Your minimal, reproducible example

https://codesandbox.io/s/vigilant-snyder-4tv39x?file=/src/main.tsx

Steps to reproduce

Press the "scroll to the top" button.
Attempt to scroll down, using either mouse or keyboard.

Expected behavior

As a user I would expect to be able to scroll the list with no issues, but the scroll position keeps jumping back to the start, making it impossible to get anywhere (without clicking one of the other "scroll to XXX" buttons).

How often does this bug happen?

Always

Screenshots or Videos

No response

Platform

Mac OS, latest version of Chrome

tanstack-virtual version

beta.36

TypeScript version

No response

Additional context

The problem appears to come in the getOffsetForAlignment method, which for "end" alignment (or "center") will return a negative offset when toOffset is in the first "page" of results. This causes problems in the timeout set for the isDynamic case in scrollToIndex because toOffset ends up being negative and therefore the approxEqual check never passes, so the list is continually thinking it needs to scroll, long after the scroll has actually been done!

The easy fix would appear to me to be to make getOffsetForAlignment never return anything less than zero - but as I am not familiar with all the package internals I obviously cannot say if that would cause issues or not.

Terms & Code of Conduct

  • I agree to follow this project's Code of Conduct
  • I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions