v3.13.8 doesn't scroll all the way to the bottom correctly

[iscekic]

Describe the bug

There seems to be a regression in v3.13.8 vs v3.13.7 - exact same code in both cases:

// somewhere above
const measureElement: Parameters<typeof useVirtualizer>[0]["measureElement"] = (
  element,
) => element.getBoundingClientRect().height;

const estimateSize = () => 72;

const virtualizer = useVirtualizer({
  count: messages?.length || 0,
  getScrollElement: () => parentRef.current,
  estimateSize,
  measureElement,
  getItemKey: (index: number) =>
    messages?.[index] ? idExtractor(messages[index]) : nanoid(),
});

// somewhere below
const lastBeforeDateIndex = messages.length - 1; // this is a bit more complicated in the actual code, but most often resolves to this

// some other irrelevant logic, including a getVirtualItemForOffset call

virtualizer.scrollToIndex(Math.max(lastBeforeDateIndex, 0), {
  align: "start",
  behavior: "smooth",
});

For context, I have an infinite list in which items (messages) are occasionally appended. The items themselves have a dynamic size. When an item is appended, the list should be scrolled all the way to the bottom, so that the last item is visible.

Your minimal, reproducible example

/

Steps to reproduce

/

Expected behavior

3.13.8 retains the same behavior as 3.13.7

How often does this bug happen?

Every time

Screenshots or Videos

3.13.7 - scrolls correctly, bottom of last item is visible

3.13.8 - doesn't scroll correctly, last item is cut off

Platform

Brave on Linux, though it seems to reproduce everywhere

tanstack-virtual version

v3.13.8

TypeScript version

v5.8.3

Additional context

No response

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.

[piecyk]

Thanks @iscekic for reporting the issue! I haven’t checked it yet, but it seems related to the loosened approxEqual logic introduced in 60719f6

[beliarh]

@piecyk I encountered the same issue. scrollToIndex no longer scrolls to the correct element.

Based on the code, the problem appears to be in replacing scrollSize with this.getTotalSize().

Code before:

const scrollSizeProp = this.options.horizontal
  ? 'scrollWidth'
  : 'scrollHeight'
const scrollSize = this.scrollElement
  ? 'document' in this.scrollElement
    ? this.scrollElement.document.documentElement[scrollSizeProp]
    : this.scrollElement[scrollSizeProp]
  : 0

const maxOffset = scrollSize - size

return Math.max(Math.min(maxOffset, toOffset), 0)

Code after:

const maxOffset = this.getTotalSize() - size

return Math.max(Math.min(maxOffset, toOffset), 0)

Previously, for window scrolling, the offset was limited by the document's content height.
Now it's limited by the virtualized list's height instead.
The farther the list is from the top of the page, the larger the error in the scroll position becomes.
Even setting scrollMargin doesn't help, as according to the code, getTotalSize subtracts this value and has no affect on the result.

return Math.max(
  end - this.options.scrollMargin + this.options.paddingEnd,
  0,
)

I assume similar logic applies to non-window scrolling as well.

Please correct me if I've misunderstood anything.

There's another interesting issue related to this bug.
If you try to scroll (using scrollToIndex) to an element that's far outside the visible area (i.e., not in the DOM), you can get stuck in an infinite scroll loop:

1. An incorrect scroll offset is calculated for the given index.
2. The page scrolls to that offset.
3. The element is still not in the DOM => back to step 1.

In PR #995, the idea of adding a counter to break the recursion was raised.
I think that would be quite helpful.

[piecyk]

@beliarh That makes a lot of sense, thanks for the detailed breakdown. I’ll try to look into it as soon as possible.

[seedydocloop]

Hi there !

I recently noticed this regression as well.

I experience the exact behavior described by @beliarh :

There's another interesting issue related to this bug.
If you try to scroll (using scrollToIndex) to an element that's far outside the visible area (i.e., not in the DOM), you can get stuck in an infinite scroll loop:

An incorrect scroll offset is calculated for the given index.
The page scrolls to that offset.
The element is still not in the DOM => back to step 1.

I found a few workarounds.

Workarounds

1. workaround for infinite scroll loop :

Instead of relying on scrollToIndex, I run my own virtualizer.getOffsetForIndex combined with virtualizer.scrollToOffset.

I didn't dig in the code, but I tested with my use case, it helps not being stuck in an infinite scroll loop.

2. workaround for doesn't scroll all the way to the bottom

I first call virtualizer.scrollToOffset, then call either :

• node.focus(), when I want to focus on a specific cell
• node.scrollIntoView(), when I want to scroll to a specific cell

I guess this would work as well if you tried to scrollIntoView the tr node.

[piecyk]

Hey I’ve opened a PR that fix scrollToIndex behavior #1029 If you're interested feel free to take a look and test it out! Feedback welcome.

[piecyk]

Can be tested via #1029 (comment) without waiting for it to be merged and published.

[piecyk]

Just released @tanstack/react-virtual@3.13.12 should fix the scrolling issue.