[bug]: MessageScroller: rAF-deferred ResizeObserver handling paints every streamed chunk one frame before the scroll correction

[ahardin]

Describe the bug

In @shadcn/react 0.3.0, the ResizeObserver callbacks on MessageScrollerViewport and MessageScrollerContent defer handleResize through requestAnimationFrame. (This deferral appears to be the fix for #11084, whose root-cause description shows the callbacks previously invoked handleResize synchronously.) The deferral trades the loop warning for a one-frame visual regression: resize observations are delivered before paint in frame N, but the handler now runs in frame N+1's rAF — so frame N paints with stale scroll state on every streamed content growth.

Concretely, streaming an assistant reply with autoScroll:

• Follow mode: each chunk paints one frame with scrollTop short of the bottom by the chunk's height. The scrollbar thumb visibly bounces off the track bottom at chunk cadence.
• Anchored mode (turn anchoring): the tail spacer is compensated one frame late, so scrollHeight wobbles by the chunk height each chunk.

The transcript content itself never visibly moves (growth happens below the fold), so the artifact shows only in the scrollbar — invisible on macOS default overlay scrollbars, obvious on classic-scrollbar platforms (Windows, Linux, macOS "Always"). Measured with a paint-accurate probe (a second ResizeObserver registered after the library's, so it is delivered later in the same frame's batch): a 60-item streamed reply painted ~170 bad frames.

Suggested fix (we run this as a pnpm patch in production; happy to PR): run the handler synchronously inside the observer callback where it is loop-safe, and defer only what is not:

1. Follow path (mode === "following-bottom"): only sets scrollTop — cannot resize anything, so it cannot re-trigger the observer. Safe to run synchronously; this alone removes the thumb bounce.
2. Anchored path: mutates the spacer (a child of the observed Content), so run it synchronously with the observer suspended around the mutation — unobserve → reanchor → observe, where the re-observe is deferred to the next animation frame (calling observe() inside the delivery cycle re-triggers the [bug]: MessageScroller fires "ResizeObserver loop completed with undelivered notifications" during streamed content growth #11084 "undelivered notifications" error), plus a last-content-height memo so the catch-up initial delivery settles instead of ping-ponging.

With that change we measure 0 stale painted frames in both modes and 0 ResizeObserver loop warnings — i.e. #11084 stays fixed.

Affected component/components

MessageScroller (@shadcn/react 0.3.0 — ResizeObserver wiring in Viewport/Content and handleResize)

How to reproduce

1. On a classic-scrollbar platform, stream an assistant reply into MessageScroller with autoScroll while scrolled to the live edge.
2. Watch the scrollbar thumb: it bounces off the track bottom on every chunk.
3. To measure: create a ResizeObserver on the Content element after the scroller has mounted (so it is delivered after the library's observer in the same batch) and record scrollHeight - clientHeight - scrollTop at each delivery — it reads 20–100px at chunk cadence instead of 0.

Codesandbox/StackBlitz link

https://stackblitz.com/github/ahardin/message-scroller-stream-repro?file=src%2FApp.jsx

(Source: https://github.com/ahardin/message-scroller-stream-repro — deterministic fake stream, no LLM/network. The toolbar checkbox toggles the registry data-autoscrolling:scrollbar-none class; the on-page counters are the paint-accurate probe described above, so the defect is measurable even on overlay-scrollbar platforms.)

Logs

No response

System Info

@shadcn/react 0.3.0, Chromium on Arch Linux (classic scrollbars); reproducible on any classic-scrollbar platform

Before submitting

• I've made research efforts and searched the documentation
• I've searched for existing issues

[ahardin]

Added a StackBlitz repro (deterministic fake stream, no LLM): https://stackblitz.com/github/ahardin/message-scroller-stream-repro?file=src%2FApp.jsx — the on-page counters implement the paint-accurate probe from the report (a ResizeObserver registered after the library's), so the stale painted frames are visible as numbers even on overlay-scrollbar platforms. On my machine it counts ~60 stale painted follow frames per 10s of streaming, and the anchored-phase scrollHeight wobble counter climbs after "New turn (anchored)".