[BUG]: followOutput breaks during fast updates (Brave, Chromium 108)

[chdwlch]

Describe the bug
followOutput breaks during fast updates

Reproduction
A sandbox containing a modified https://virtuoso.dev/stick-to-bottom/ example.
I changed data generation from 400ms to 100ms
https://codesandbox.io/s/sandpack-project-forked-1g9yfw?file=/App.js

To Reproduce
Steps to reproduce the behavior:

1. Open the example codesandbox
2. Allow it to run
3. After ~1-5 seconds observe the output no longer being followed

Expected behavior
Output should continue being followed

Desktop (please complete the following information):

• OS: macOS Monterey v12.4
• Browser: Brave 1.46.134 Chromium v108.0.5359.95 (arm64)

I am NOT seeing the same issue running on Safari version 15.5 (17613.2.7.1.8)

Additional context
Sticking to the bottom seems to be more reliable with followOutput set to 'smooth' during fast updates.

Additional discussion about this issue can be found in here. Mine is slightly different due to using 'auto' for followOutput which should be used for fast updates.
#317 (comment)

[petyosi]

Do you see the same problem in Chrome? Because I don't (Vanilla Chrome v109).

[chdwlch]

I am now able to see the problem on Chrome, Brave, and Safari. I realized it happens when the width of the Virtuoso component shrinks enough to where some of the text displayed begins to overflow.

If you shrink the width of the example code sandbox's browser while running you can watch it happen. I also removed any margin from the list items.

Here's a screenshot after the followOutput stops for me on Vanilla Chrome v109

[petyosi]

OK, that explains it. This is a known limitation, here's the summary:

• followOutput is basically scrollToIndex when a change in totalCount happens.
• scrollToIndex to an item that hasn't been rendered previously assumes the item has the "default" height (this is usually the height of the first rendered item). This can be changed with defaultItemHeight, which is usable in certain cases, but not always.
• If the height of the new item is different than the expected, scrollToIndex retries until no new item height measurements are received.
• The above involves rendering cycles, and (unfortunately) timers.
• Updates that are pushed in within the retry will break the retry.

The example above can sometimes meet those conditions (if the first rendered item has one-line text, while the subsequent ones have two lines, this is why the sandbox viewport width matters). There's a more reliable way to reproduce it, by making the first item shorter.

The workaround I can recommend is to reduce the update frequency to at least 200ms by throttling. Also, you can extend the viewport to the bottom, so that newly introduced items are rendered before scrollToIndex happens.