RecycleScroller: Missing rows on rapid scrollbar use

[yestellar]

Describe the bug

Hello,

I've encountered an issue with RecycleScroller while displaying a list of 10,000 items. When I scroll quickly using the scrollbar (not the mouse wheel), some rows fail to display, creating what appears as gaps in the list. This problem seems to stem from incorrect transformY calculations and typically arises after a few seconds of rapid scrolling, becoming more frequent thereafter. Is this a known issue, or could it be a result of my configuration?

Reproduction

System Info

Browser: Chrome
Vue version: ^3.4.15
vue-virtual-scroller version: ^2.0.0-beta.8

Used Package Manager

npm

Validations

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[yestellar]

I didn't encounter this issue after downgrading to version v2.0.0-beta.3.

[srackhall]

I have also encountered this problem, but I can only quickly call the up and down scrolling API through the dom element in the code to eliminate this problem. This should be a bug in the library itself. Unfortunately, the author seems to have no time to maintain this library in the short term and seems to be focusing on other projects.

[ferflores507]

I didn't encounter this issue after downgrading to version v2.0.0-beta.3.

As I'm also experiencing this issue and can confirm you are correct. If you go some commits further and before v2.0.0-beta.4 you will find a commit with a simple change that produced the bug: 11488b7#diff-81ba54d7792972724aef9126b122a8b00d2f24654aa50fba1ef50fd5f2e57d39L498

The commit was a single line change with "fix" title but doesnt include enough information about what was fixing and is confusing:

It is important to know that version v2.0.0-beta.8 includes an improved version of the code in the screenshot but the containing method needs to be rewritten because it is too long (updateVisibleItems has nearly 250 lines of code).

To end this long history I see it difficult to have a stable version soon if the authors keep doing bug fixes attemps instead of doing a hard code refactoring first.

There is a duplicate issue if you want to check #882.

Thanks!