You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug report] jumpTo scrolls instead of jumping #155
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.44.6, on macOS 26.6.2 25G83 darwin-arm64, locale en-KZ)
[✓] Android toolchain - develop for Android devices (Android SDK version 36.1.0)
[✓] Xcode - develop for iOS and macOS (Xcode 26.6)
[✓] Chrome - develop for the web
[✓] Connected device (3 available)
[✓] Network resources
• No issues found!
How to reproduce?
Run _observerController.jumpTo(index: 100); and it will scroll over all item up until 100th item.
Hi @yerzhant, thanks for the report — this is expected behavior rather than a bug.
When you don't pass isFixedHeight, the package has no way to know the total extent of the 100 items above the target, because they haven't been laid out yet. So it falls back to walking toward the target: it jumps one viewport at a time, frame by frame, until the target index enters the viewport. Each of those steps renders a frame, which is why it looks like the list is scrolling through everything.
This is documented in the doc comment of jumpTo:
If you do not pass the isFixedHeight parameter, the package will automatically gradually scroll around the target location before locating, which will produce an animation.
Two ways to get a real jump:
If your items (and separators) have a fixed height, pass isFixedHeight: true:
The offset is then calculated directly and the list jumps in one step.
If the heights are dynamic, there's no way to compute the offset ahead of time, so the step-by-step approach is unavoidable on the first jump. However, cacheJumpIndexOffset is enabled by default, so the offset of index 100 is cached after the first jump — jumping to the same index again will be instant.
If your items do have a fixed height and isFixedHeight: true still scrolls, please share a minimal reproducible sample and I'll take another look.
One must say that the scrollable_positioned_list package jumps immediately to the desired element in one hop. I do not know how they implemented that. Maybe they directly take 100th element and lay it out and plus some previous elements that are cached so if one scrolls down that they smoothly slide in to the viewport.
Activity
LinXunFeng commentedon Sep 7, 2026
Hi @yerzhant, thanks for the report — this is expected behavior rather than a bug.
When you don't pass
isFixedHeight, the package has no way to know the total extent of the 100 items above the target, because they haven't been laid out yet. So it falls back to walking toward the target: it jumps one viewport at a time, frame by frame, until the target index enters the viewport. Each of those steps renders a frame, which is why it looks like the list is scrolling through everything.This is documented in the doc comment of
jumpTo:Two ways to get a real jump:
If your items (and separators) have a fixed height, pass
isFixedHeight: true:The offset is then calculated directly and the list jumps in one step.
If the heights are dynamic, there's no way to compute the offset ahead of time, so the step-by-step approach is unavoidable on the first jump. However,
cacheJumpIndexOffsetis enabled by default, so the offset of index100is cached after the first jump — jumping to the same index again will be instant.If your items do have a fixed height and
isFixedHeight: truestill scrolls, please share a minimal reproducible sample and I'll take another look.yerzhant commentedon Sep 8, 2026
Hi @LinXunFeng, thank you for the explanations.
One must say that the scrollable_positioned_list package jumps immediately to the desired element in one hop. I do not know how they implemented that. Maybe they directly take 100th element and lay it out and plus some previous elements that are cached so if one scrolls down that they smoothly slide in to the viewport.