Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
  • 何か問題がありますか？
#13,706 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
82/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
frontend, performance, web-dev

調査の方向性

patches/@[email protected] から始め、getItemSize、setSize、addTotalSize を通る prepareMVCP のサイズチェックを追跡してください。Issue に記載されたスタンドアロンの LegendList 再現例を使ってジャンプを検証し、その後、アニメーションスクロール中に最後の行を削除してもリストが折りたたまれたり、先頭付近に移動したりしなくなったことを確認してください。

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
23.6k
フォーク
6.1k
平均マージ
9時間 26分
マージ済み PR（30日）
340

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

pingdotgg/t3code のほかの issue

pingdotgg/t3code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。