[Bug]: Returning to a long thread lands at the top or the middle instead of where I left it #14051

Activity

1. Vantrongs

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 28, 2026
2. juliusmarminge commented on Sep 28, 2026

   

   juliusmarminge

   on Sep 28, 2026

   Member

   More actions

   Triage: #14051

   Verdict: Confirmed bug for switching back to a thread you left at the bottom. Same cache bug as #13601, with a wider trigger than an in-flight stream. Not a duplicate. Not fixed on main.

   Confidence: High for that switch-back path. The cited lines match 94f92a7 and current main (d15210cd); nothing in between touches this code. Not reproduced in a browser here. The relaunch sentence is a different path, and the position cache cannot cause it.

   What is wrong

   A long thread left at the latest message can reopen at the top or in the middle, with "Scroll to end" showing. The session cache stored a reading position even though live follow was still on.

   Cause

   handleScroll writes the geometric end check straight into the per-thread cache:

           rememberTimelinePosition(listIdentityKey, {
             ...position,
             // DOM geometry includes the header and the virtualizer's layout adjustment.
             offsetWithinRow: element.getBoundingClientRect().top - row.getBoundingClientRect().top,
             scrollOffset: element.scrollTop,
             atEnd: isAtEnd,

   isAtEnd is resolveTimelineIsAtEnd: a gap of more than 40px counts as not at the end (MessagesTimeline.logic.ts). Nothing in that write checks that the user scrolled. LegendList calls onScroll for layout movement, and a row-count effect calls handleScroll again one frame after rows.length changes (MessagesTimeline.tsx around 1102).

   Two layout cases can open that gap while the user is still sitting at the bottom:

   • Rows are estimated at 90px (estimatedItemSize={90}). A tool or markdown row that measures taller leaves the viewport more than 40px short until follow catches up.
   • maintainScrollAtEnd sets footerLayout: false on purpose, so composer growth does not re-pin.

   onIsAtEndChange in ChatView.tsx (around 5640) already ignores isAtEnd === false while the follow latch is held, so the pill stays hidden and follow stays on. The cache does not get that exception.

   On the next visit, the thread-switch effect (around 5724) treats atEnd === false as free-scrolling, turns live follow off, and shows the pill. Restore then scrolls to the saved row, or to scrollOffset when that row is missing (MessagesTimeline.tsx around 864). A missing row also finishes the restore immediately, so a later snapshot does not retry.

   Desktop uses this web timeline. Mobile ThreadFeed does not use rememberTimelinePosition. The provider does not matter.

   What the report gets wrong

   The position cache is an in-memory Map in timelineScrollAnchoring.ts. It dies with the renderer. A desktop relaunch cannot restore atEnd: false from the previous session. A cold open has no saved position, so ChatView follows the end and the timeline uses initialScrollAtEnd / scrollToEnd. Opening in the middle after a relaunch is a real-looking symptom, but it is not this cache bug. The likely neighbor is scrollToEnd against the 90px estimates on a tall first page (the last 10 user turns, INITIAL_THREAD_USER_TURN_LIMIT), if item-layout re-pin does not win. That needs its own trace.

   The pixel fallback is also narrower than the write-up. scrollToOffset uses the stored offset. A large offset from a longer list, applied to the short first page, clamps to the end of that page (the latest turns), not the top. It lands at the top or the middle only when the stored offset itself was small or mid-list, which is what a measurement gap or a list reset saves. The snapshot replacement in threads.ts (around 453) does drop older pages. That is not, by itself, an at-end restore jumping to the top.

   Not a duplicate

   Issue	Why it is different
   #13601	Same cache write, confirmed while a stream's follow glide was behind. This report's repro is an idle thread: scroll to the bottom, switch away, switch back. Layout and footer growth can save atEnd: false without a stream. Fix is the same PR.
   #5903	Umbrella symptom (open or finish above the latest message). Still open. This is one cause: a follow gap saved as a reading position, pill visible.
   #12372	Opposite cache bug. Position saved as atEnd: true, viewport stranded, pill hidden until a nudge.
   #12222	Restore completes against the previous thread's rows and sticks at the top. Open PR. This report restores a saved offset and shows the pill. Worth having if a switch still lands at the top after atEnd is fixed.

   Cross-link #14051 to #13601 and #5903. Do not close it as a duplicate.

   Already fixed?

   No. #13602 (fix(web): reopen a thread that was following its stream at the end, open, not merged) is the switch-back fix: remember atEnd: isAtEnd || (liveFollowEnabled && isLiveFollowLatched() && !anchoredEndSpace). The latch is the ref ChatView already uses to ignore follow lag, and anchored end space is excluded so a first send held near the top is not stored as the end. That covers this report's idle-at-the-bottom case whenever follow is still latched, including footer growth and a measurement gap.

   It does not change cold open. A relaunch that still lands in the middle after #13602 is the estimate / re-pin path, not this cache.

   Next step

   Keep #14051 open. Label it bug + accepted, and take off needs-triage. Review #13602 rather than starting a second patch. Workaround until that lands: "Scroll to end" or End.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 28, 2026