Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: Timeline jumps far up right after sending in a long thread

Aperta Adatta ai principianti
  • Qualcosa non va?
#13,706 1 commento 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@santiago-ramos-02 ci sta già lavorando.

Dal 25/9/2026.

  • #13707 di @santiago-ramos-02 — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
82/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend, performance, web-dev

Direzione di ricerca

Inizia con patches/@[email protected] e segui il controllo delle dimensioni di prepareMVCP attraverso getItemSize, setSize e addTotalSize. Usa la riproduzione standalone di LegendList descritta nell’issue per verificare il salto, quindi conferma che la rimozione dell’ultima riga durante uno scorrimento animato non fa più collassare la lista né la sposta vicino all’inizio.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/web

Steps to reproduce

In the app it is timing dependent. It shows up most in long threads with long replies, especially on desktop with a busy main thread:

  1. Open a thread with a lot of history and long assistant replies, scrolled to the bottom.
  2. Send a message.
  3. About half a second later the timeline jumps far up, often near the top of the loaded history, and stays there.

A small page that renders only a LegendList (no T3 Code components or data), served by the apps/web dev server, reproduces it every time:

  1. Render a LegendList with 150 rows of about 900px each, estimatedItemSize={90}, initialScrollAtEnd, and maintainVisibleContentPosition={{ data: true, size: true }} (the timeline's options).
  2. Scroll up a few screens.
  3. Call listRef.current.scrollToEnd({ animated: true }).
  4. While that scroll is running, remove the last row from data.
Expected behavior

The list ends at the end, with 149 rows.

Actual behavior

The list lands on rows 0 and 1, about 25,000px from the end. The same steps without step 4 end at the end. Removing the last row without a scroll in flight keeps the position.

The same page reproduces in a separate plain app with pristine npm @legendapp/list 3.3.5, when built with Rolldown-based Vite (apps/web builds with Rolldown through vite-plus). With esbuild-based Vite it does not jump. Under the same Rolldown setup, 3.4.0 does not jump either.

Impact

Major degradation or frequent failure

Version or commit

main @ ed809f7ad2 (@legendapp/list 3.3.5 with T3 Code's patch). @legendapp/list 3.4.0 does not reproduce. Its changelog lists "End-following and animated programmatic scrolling now stay aligned through footer, viewport, and native layout changes."

Environment

Windows 11, desktop nightly and web client from vp run dev. Provider independent. The same code is in the React Native build that mobile uses.

Logs or stack traces

No errors. Reading listRef.current.getState() every frame during a jump in a long thread:

Time after send scroll contentLength Rows in data Rendered rows
before 12,414 13,162 144 131 to 143
631 ms 0 334 143 131 to 142
1,047 ms 12,158 49,291 143 36 to 39

The element's scrollTop stayed about where it was the whole time; only LegendList's state reset. The row data never went empty. A totalSize listener caught the collapse. Its stack runs through checkResetContainers, calculateItemsInView, the MVCP check, getItemSize, setSize, and addTotalSize.

Screenshots, recordings, or supporting files

The standalone repro, unpatched:

https://github.com/user-attachments/assets/22c266c7-1763-42e4-ae23-851b2de6cc01

Workaround

Press End or use "Scroll to end".

Cause

scrollToEnd records the last index as state.scrollingTo. When data shrinks before that scroll completes, the MVCP check in prepareMVCP resolves the target with getId(state, scrollTarget). That index is now past the end of data, so it returns null. The check still sizes it:

if (scrollingToViewPosition && scrollingToViewPosition > 0) {
  const newSize = getItemSize(ctx, targetId, scrollTarget, state.props.data[scrollTarget]);

getItemSize passes the null key to setSize, and addTotalSize treats a null key as "set the total to this value". The total height collapses to one estimated row. That sends the list to scroll = 0 and it re-lays out unmeasured rows at the average measured row height. In a thread of long replies that average is several times the 90px estimate, so the old offset now lands near the top.

In T3 Code the shrink comes from the timeline's trailing rows. When a turn starts, the live activity row at the end is replaced, which briefly removes one row while the send's scrollToEnd is still in flight. A busy main thread widens that window. The desktop running-thread keep-alive and very large environments made it frequent here, but neither is required.

Skipping that size check when targetId is null fixes the repro. I'll open a PR that adds the guard to patches/@[email protected].

Lingua principale
TypeScript
Stelle
24.8k
Fork
6.4k
Merge medio
11h 33m
PR unite (30g)
312

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pingdotgg/t3code

Tutte le issue di pingdotgg/t3code

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.