Erratic behaviour with onRangeChange while scrolling up

[mrooding]

Describe the bug
When using a Virtualizer with a list index component to jump to a specific point within the list, scrolling upwards really quickly after loading makes the scrollbar jitter. It continuously calls range change event handler until it reaches start index 0.

To Reproduce
Video: https://photos.app.goo.gl/j9SXEJGUyirVuCyY7

Expected behavior
It should just load the previous items once and not loop all the way back to 0

Platform:

• OS: MacOS
• Browser: Electron
• Version of this package: 0.33.3
• Version of framework: vue 3.4.27

Additional context

I'm trying to implement a virtual list that supports a list index component used for jumping to a specific index. Regular horizontal scrolling from the start of the list until the end works perfect.

After using the list index to jump to a specific offset, scrolling downwards to load higher index items works fine too. However, when scrolling upwards extremely fast seems to create a state where the scrollbar is stuck and a update loop is triggered which loads all the items until index 0 is reached.

I've tried using a normal VList instead of a Virtualizer (with scroll-ref) but that had the same effect. I've based my implementation on the feed example

Simplified usage of the component:

 <Virtualizer
      v-slot="item"
      ref="virtualizer"
      :item-size="85"
      :data="list.items"
      :scroll-ref="scrollRef"
      :shifting="shifting"
      @range-change="onRangeChange"
    >
      <component
        v-if="item"
        :key="item.index"
        :item="item"
      />
    </Virtualizer>

[inokawa]

Hi, could you make a minimal reproduction?

[mrooding]

Hi @inokawa I've created an isolated electron app that's as close as possible to how the actual app functions. If possible, I'd like to share it privately. Could you let me know how I could do so?

[WalrusSoup]

I want to chime in and say I've also been experiencing this, and I have some theories on what's causing it.

When I trip the loader to load more, the load happens but the scroll has continued to move up during that same period (inertial scrolling?). Because I'm only appending 25 items to the head of the list, the visible range is immediately put back into the "go get more to load" state due to the upward momentum.

I have a really weird fix where i basically timeout the ability to load more for 1.5s, and after a mutation and a nextTick(), I move the scroll position back to where it should be (i mark the item that was at the top prior to when I started loading). This is... not great, because the scroll is still basically firing. So for end users, it kinda just feels like they are shoved back down and then it pops around.

@mrooding i think maybe you could be experiencing the same thing?

[mrooding]

@WalrusSoup that's interesting. Even without this bug I noticed that the range change event handler was firing very often so I already introduced a debounce function. That didn't seem to fix it for me though. Possible, manually moving the scroll position would fix it like you did.

Would you be able to share an isolated example of your solution?

@inokawa @WalrusSoup I've stripped the example app to the bare minimum of what my overall setup looks like: https://drive.google.com/file/d/1RiToR4mq0iitkQKbbg6vQ_DdDy7ubGEi/view?usp=sharing

To reproduce:

1. Install dependencies using pnpm install
2. Run the app using pnpm watch
3. Move your cursor to the right side of the window so that the list index appears
4. Click on one of the list index options in the middle or near the end of the list (e.g. L).
5. Try scrolling down and upwards

[inokawa]

Thanks! I'll take a look.

[inokawa]

Your application logic fetches new items in onRangeChange callback. Prepending items will change visible range so onRangeChange can be called infinitely if we don't have proper guard. So please consider adding guard.

[mrooding]

@inokawa thank you for the reply. What would a proper guard look like to you?

[mrooding]

Hi @inokawa I'd appreciate your input on this one. Thanks again