fix(web): threads open at the newest message, not thousands of pixels above it

[t3dotgg]

A long thread opened from an empty or loading pane could stop well above its newest message. Our restoration scroll replaced LegendList’s measured initial end target with an estimated one.

The timeline now records the thread on which a list instance first mounted and leaves that initial end target intact. Saved reading positions and switches that reuse an existing list retain their restoration behavior.

Original fix by @t3dotgg in #19663, building on @bompus’s investigation. Contributor commits and credit are preserved.

Verification:

• One PR-added regression retained (1→1) in the existing MessagesTimeline.browser.test.tsx; the existing reading-position test also covers reopening and thread switches. Removing the fix makes cold entry stop 20,912px above the end. Final focused suites: 72 browser and 205 unit tests passed (277 total).
• Scoped web typecheck, targeted lint, formatting and diff checks passed.
• Independent Claude Opus 5.5 and GPT-6 Sol full-diff review: two rounds; first round identified a return-to-end coverage gap. The existing cold-entry test now covers it and fails 2,000px above the end when the identity clearing is removed. Final round: no blockers.
• Integrated Linux Chromium web app with synthetic stored messages at 1280×800: main stopped 2,152px above the end; this head reached 0px and remained there across 30 layout frames. A manual reading position restored the identical paragraph and pixel offset after switching threads; an end-position switch also returned to 0px. DejaVu Sans used for both captures.

Before (main):

After:

Cold-entry recording: Before · After

The settled/snoozed empty-footer variant was not verified live.

Not verified: macOS, Windows, iOS, Android or Electron desktop. Native mobile has a separate timeline and is outside this fix. Safari/WebKit and Electron remain human checks.

Tests: GPT-6 Astra; implementation: GPT-6.1 Sol; adversarial reviews: Claude Opus 5.5 and GPT-6 Sol. Codex and Claude Code harnesses, delegated through T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 714165e

Macroscope's review found this PR approvable — This is a focused web bug fix that preserves measured initial scroll positioning without changing saved-position behavior, with targeted browser regression coverage. Its runtime impact is localized to thread opening and reuse, with no sensitive, schema, deployment, or static-analysis changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Team
• Run ID: dba9fa51-ad7d-4eae-9679-2a2359190d53

📥 Commits

Reviewing files that changed from the base of the PR and between bc7efe2 and 714165e.

📒 Files selected for processing: 2

• apps/web/src/components/chat/MessagesTimeline.browser.test.tsx
• apps/web/src/components/chat/MessagesTimeline.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 1 remain after this review.

📝 Walkthrough

ConversationTimeline tracks the thread associated with its list and skips end scrolling when the list is already associated with that thread. Browser tests cover end-position and saved-offset restoration after loading messages, reopening the chat, and switching threads.

Changes: Thread-aware timeline scrolling

Layer / File(s)	Summary
Track list identity and restore positions apps/web/src/components/chat/MessagesTimeline.tsx, apps/web/src/components/chat/MessagesTimeline.browser.test.tsx	The timeline records the thread identity associated with its list and skips scrollToEnd when that list is already associated with the current thread. Browser tests cover reaching the newest message after an empty timeline, reopening the chat, switching threads, and restoring a saved offset.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: maria-rcks, juliusmarminge

Merge Risk: ⚪ Minimal · up to 71416

Long threads should now open at the newest message instead of stopping far above it. Saved reading positions and thread switches keep their existing behavior. No actionable merge-blocking risk remains.

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the primary fix: threads now open at the newest message instead of far above it. It uses a valid conventional commit format.
Description check		The description clearly explains the problem, implementation, verification results, test coverage, screenshots, recordings, and unverified platforms. It does not use the template headings and does not…

Full details: Description check

Explanation

The description clearly explains the problem, implementation, verification results, test coverage, screenshots, recordings, and unverified platforms. It does not use the template headings and does not explicitly document maintainer approval or explain why approval was unnecessary, so the Scope and approval section could be improved.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.9 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	−24 B (−0.5%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	−24 B (−2.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	−41 B (−0.2%)	29.3 KiB	✅
Claude	Live turn messages	2	1	−1 (−50.0%)	8	✅

Baseline: 40a7908 · PR result: 34709d2 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

Dismissing prior approval to re-evaluate bc7efe2

[juliusmarminge]

Taking over this one. I will preserve saved reading positions, verify the cold-entry fix against current main, and push the focused update here.

Dismissing prior approval to re-evaluate 714165e