[WEB] Scrollbar oscillation cause infinite layout loop

[VickyStash]

Description

On web with classic (non-overlay) scrollbars — i.e. Windows/Linux Chrome and macOS with "Always show scroll bars", FlashList v2 can enter an infinite layout loop and crash with Maximum update depth exceeded because the vertical scrollbar's own appearance/disappearance feeds back into the list's cross-axis (width) measurement.

When list content height sits right at the threshold where it just barely overflows the viewport, the browser shows a vertical scrollbar. The scrollbar consumes ~15–17px of width, which reduces the measured client width FlashList uses as boundedSize. The narrower width re-flows items so the content no longer overflows → the scrollbar is removed → the measured width grows back → content overflows again → the scrollbar returns → and so on, forever.

This is web-specific: native platforms use overlay scrollbars that don't consume layout width, so they never oscillate.

Current behavior

• The list rapidly re-lays-out, the scrollbar visibly flickers, and React throws Maximum update depth exceeded (setState loop in updateLayoutParams → recompute layout → measure → updateLayoutParams …), crashing the app.
• Happens whenever content size is near the boundary at which adding/removing the scrollbar flips whether the content overflows.

Expected behavior

FlashList should not let the scrollbar's own width feedback-loop the layout.

Reproduction

Expo Snack or minimal reproduction link:

Make sure to test on web with classic (non-overlay) scrollbar. If you use MacOS fo to Settings -> Appearance -> Windows -> Show scroll bars -> Always.

https://snack.expo.dev/@vikstash/flashlist_loop_crash

Platform

• iOS
• Android
• Web (if applicable)

Environment

React Native info output:

Paste output here

FlashList version:
2.3.0

Additional context

Root cause is in LinearLayoutManager.ts, method updateLayoutParams. boundedSize is taken directly from the measured window size with no detection of scrollbar-induced oscillation, so the scrollbar appearing/disappearing keeps changing the measured width and re-triggering layout.

Checklist

• I've searched existing issues and couldn't find a duplicate
• I've provided a minimal reproduction (Expo Snack preferred)
• I'm using the latest version of @shopify/flash-list
• I've included all required information above

[VickyStash]

I've shipped a patch-package workaround for this in Expensify/App: patch link.

Patching LinearLayoutManager.updateLayoutParams to detect the scrollbar-induced oscillation on web and settle on a stable cross-axis size. The approach keeps the last 4 rounded cross-axis sizes and treat a change as scrollbar-induced only when all of these hold, so a genuine manual window resize is never misread:

1. the last 4 sizes strictly alternate between exactly two values (A, B, A, B — 3 consecutive flips, which a drag-resize doesn't produce on the same two pixels);
2. the two values differ by no more than a scrollbar's width (≤ 25px tolerance for thicker/zoomed scrollbars).

When detected, we settle on the smaller of the two values (it already accounts for the scrollbar, so items never overflow the client width).

Happy to raise a PR with this approach if there are no better ideas — but if there are better ideas (e.g., handling it at the measurement layer rather than in the layout manager), I'm glad to follow that direction.
Just let me know what you think!