Repository navigation
Returning after a background reply finishes still leaves the timeline above the newest message #22111
Description
What happened
I switched away from a thread while following its streaming reply, then returned after it finished. The view stayed above the newest message with no "Scroll to end" button.
Diagnosis
The restore scroll targets estimated row heights. A completed reply loads as a batch taller than the viewport, leaving the list outside its follow threshold.
Steps to reproduce
- Open a long thread with markdown and tool output.
- Start another long reply and scroll to the end so it follows.
- Switch to another thread while it streams.
- Return after the reply finishes.
Expected: return to the newest message. Actual: the view remains thousands of pixels above it after layout settles.
Version
Reproduced on nightly 0.1.1-nightly.20261019.3373, which includes #19663, and unmodified main 6a049d0.
Environment
Linux web client, Chromium, 1280 by 800 CSS pixels; synthetic conversations with real Codex streams. Stable v0.1.0, packaged desktop, mobile and remote connections were not tested.
Evidence
The recorded main build stayed 6,295 px above the end with no button throughout 8.4 seconds. A focused local correction reached 0 px and stayed there as rows grew. These are reproduction runs with different generated replies, not a benchmark or failure-rate estimate. Before/after screenshots, recordings and 96 passing focused tests are in https://github.com/bompus/t3code/pull/15.Related issues
Filed as requested in #5903 (comment). #12372 separately tracks missing-button visibility. #14051's follow-cache cause was addressed by #17348, which is included in these tested builds.
Fix applied or workaround
No installed-app changes. Scrolling up and down can reveal the button, then clicking it reaches the end. I can open the focused pull request once triage confirms the direction. The branch is ready in the linked fork PR. It preserves existing follow intent during row measurement and stops on user navigation; it does not change the missing-button guard.
Filed by
Claude Sonnet 5.5 through Claude Code in T3 Code investigated and wrote the original fix. GPT-6.1 Sol through Codex in T3 Code verified it and corrected a review finding.
Activity
juliusmarminge commentedon Oct 20, 2026
Note
Grok responding on behalf of Julius.
Thanks for filing this separately from #5903. The return path on current main fits your diagnosis. When the remembered position is at the end, the timeline either keeps the list's own initial scroll to the end, or calls
scrollToEndonce (apps/web/src/components/chat/MessagesTimeline.tsx:924-938). Right after that scroll it marks the thread as positioned (lines 939-943). Rows start from a 90px estimate (line 1492). The settle loop that keeps a restored row in place while rows measure only runs for a saved position above the end. So when a reply that finished while you were away measures much taller than estimated, nothing pulls the view back to the end.#14051 is the broader report of returning to a long thread at the top or the middle. This is a narrower case with a clear trigger, a reply that completed while away and an end position to restore, so it stays its own issue. Linking the two since the fix may help both.
Accepting this as a bug.