[Bug]: Scroll-to-end pill stays hidden after thread switch strands viewport above the end

[bompus]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Related: #5903 (this is the stale-pill half split out per discussion there).

Area

apps/web

Steps to reproduce

1. Open a thread with enough history to overflow the viewport.
2. Send a prompt, then switch to a different thread while the turn runs.
3. Return to the first thread after its response has landed.
4. Observe the viewport: it can be stranded above the newest message, often farther up than where it was left.
5. Observe the "Scroll to end" pill: it does not appear. Nudge the scroll up/down a little and the pill appears.

Expected behavior

If the viewport is not at the live edge, the "Scroll to end" pill is visible. The end-state tracking reflects the actual viewport position after a thread switch settles, including content whose height changes after rendering.

Actual behavior

The pill stays hidden on the stranded viewport, as if the state believes it is already scrolled to the end when it is not. Only a manual scroll nudge (which fires real scroll events) makes the pill appear.

Impact

Major degradation or frequent failure

The stranded viewport looks settled, and the missing pill removes the visible recovery path; END key is the only recourse.

Version or commit

Local checkout @ dc49767

Environment

T3 Code web/desktop client (Linux). Provider-independent; affects the shared web timeline.

Logs or stack traces

No associated exception or console error.

Screenshots, recordings, or supporting files

No response

Workaround

Nudge the scroll wheel up/down until the pill appears, or press END to jump to the live edge.

Suspected mechanism (from code reading, not runtime-verified)

• The position cached for the background thread was saved with atEnd: true (timelineScrollAnchoring.ts), so the thread-switch effect in ChatView.tsx takes the scrollToEnd branch and hides the pill.
• Transient isAtEnd=false scroll events during settle are suppressed by the post-open live-follow guard (onIsAtEndChange early return when the scroll generation still matches) plus the 150ms show-debounce.
• If row heights settle after that (streamed markdown/tool output measuring late), the viewport strands with isAtEndRef stale-true and no further scroll event corrects it.
• A manual wheel gesture bumps the generation via cancelTimelineLiveFollowForUserNavigation, letting the next isAtEnd=false through so the pill appears.

A post-settle reconciliation (re-resolve isAtEnd from the list state a frame or two after position restore completes and sync the pill) would cover this class of stranding regardless of which layout pass caused it.

[juliusmarminge]

Triage

Verdict: Valid bug. Keep open.
Not a duplicate of #5903. That issue is the stranded viewport. This one is the missing recovery affordance after the viewport is already stranded. Split on purpose; both can be true at once.
Not already fixed on current main (53510d44e). The paths in the report still match. I did not runtime-repro the thread-switch (same as the original report: code-backed, not click-verified).

What happens

1. Leave a thread while following the live edge. MessagesTimeline handleScroll writes atEnd: true into the session cache (rememberTimelinePosition).
2. Come back. The thread-switch effect in ChatView treats missing/true as follow-end: it sets isAtEndRef, arms liveFollowUserScrollGenerationRef to the current scroll generation, and hides the pill.

  useEffect(() => {
    setPullRequestDialogState(null);
    const followEnd = readTimelinePosition(routeThreadKey)?.atEnd !== false;
    isAtEndRef.current = followEnd;
    // ...
    liveFollowUserScrollGenerationRef.current = followEnd
      ? anchorUserScrollGenerationRef.current
      : null;
    // ...
    showScrollDebouncer.current.cancel();
    setShowScrollToBottom(!followEnd);

3. Restore for atEnd !== false calls scrollToEnd and skips the two-frame row reconcile used for saved reading positions. handleScroll is a no-op while restoringThreadPosition is true.
4. Late row-height changes (streamed markdown / tool output) go through onItemSizeChanged={reportContentOverflow} only. That updates composer overflow. It does not re-resolve isAtEnd or call onIsAtEndChange.
5. If a later isAtEnd=false does arrive, the post-open live-follow guard still drops it: same generation → cancel the 150ms show debounce, keep the pill hidden, leave isAtEndRef stale-true.

  const onIsAtEndChange = useCallback((isAtEnd: boolean) => {
    if (
      !isAtEnd &&
      liveFollowUserScrollGenerationRef.current === anchorUserScrollGenerationRef.current
    ) {
      showScrollDebouncer.current.cancel();
      setShowScrollToBottom(false);
      return;
    }

6. A wheel/nudge calls cancelTimelineLiveFollowForUserNavigation, bumps the generation, and the next isAtEnd=false can show the pill. That matches the reported workaround.

The guard is doing its job for streaming flicker (content grows, follow-scroll catches up). The bug is that after an atEnd restore plus a late measure, false is persistent, not a flicker, and nothing reconciles the pill.

Related (do not close as these)

Item	Why it does not close this
#5903	Viewport position, not pill state
#5905 (open, claims to close #5903)	Follow-the-edge; does not add a post-settle pill sync
#10773 (open)	Composer-reservation re-pin. After that fix the pill is hidden correctly because the viewport is at the end
#12317 (merged)	Pill-mount overlay jump, not show/hide
#12144 (merged)	The atEnd cache this restore path reads

Suggested fix (small, web-only)

Do not remove the live-follow guard (that will flash the pill during streams). After atEnd restore completes, and again on item-size changes, re-read resolveTimelineIsAtEnd from list state. If it stays false after a frame or two, treat that as a real leave-end: clear the follow generation and show the pill. onItemSizeChanged is the better hook than “two frames after restore” alone — late markdown can land well after two frames.

No new issue needed. Label bug.