[Bug]: Timeline jumps far up right after sending in a long thread
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 82/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- frontend, performance, web-dev
调研方向
从 patches/@[email protected] 开始，跟踪 prepareMVCP 的大小检查经过 getItemSize、setSize 和 addTotalSize 的流程。使用 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:
- Open a thread with a lot of history and long assistant replies, scrolled to the bottom.
- Send a message.
- 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:
- Render a
LegendListwith 150 rows of about 900px each,estimatedItemSize={90},initialScrollAtEnd, andmaintainVisibleContentPosition={{ data: true, size: true }}(the timeline's options). - Scroll up a few screens.
- Call
listRef.current.scrollToEnd({ animated: true }). - 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
- 星标
- 24.8k
- 派生
- 6.4k
- 平均合并
- 8 小时 4 分钟
- 30 天内合并 PR
- 199
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
pingdotgg/t3code 的其他 Issue
-
[Bug]: Device screenshot fails with 500 on iPhone Duo (Xcode 27.2): serve-sim calls simctl without --display可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 66/100
pingdotgg/t3code#24900 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
pingdotgg/t3code#24800 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
[Bug]: Desktop startup briefly warns about Codex provider status before its initial check completes未关闭
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 70/100
microsoft/playwright#43640 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 82/100
grasshopper-protocol/grsshppr#172 ·
维护者通常 1 天内回复
-
bug help wanted
难度 2/5 1-3 小时 新手友好度 78/100
Tencent/teamai-cli#1397 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
DouyinFE/semi-design#3641 ·
维护者通常 3 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复