Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#13,706 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@santiago-ramos-02 ya está trabajando en esto.

Desde el 25/9/2026.

  • #13707 de @santiago-ramos-02 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
82/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
frontend, performance, web-dev

Línea de trabajo

Comienza con patches/@[email protected] y sigue la comprobación de tamaño de prepareMVCP a través de getItemSize, setSize y addTotalSize. Usa la reproducción independiente de LegendList descrita en el issue para verificar el salto y, después, confirma que eliminar la última fila durante un desplazamiento animado ya no colapsa la lista ni la mueve cerca de la parte superior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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].

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
2 h 58 min
PR fusionados (30 d)
480

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.