[BUG] scroll-to-bottom can get disengaged/interrupted when generating long thinking blocks

[Jerrill]

Problem (one or two sentences)

When Roo is streaming long thinking blocks (and possibly long mode handoff messages) scroll-to-bottom can get disengaged. The long block may even scroll to bottom for a while and then disengage scroll-to-bottom before it's completed.

Context (who is affected and when)

I'm experiencing this issue when running multiple instances of VSCode and the system as a whole is under high CPU load. It's not clear whether the system load is significant, but the issue is frequent enough to be very visible when monitoring multiple VSCode instance for Roo Code extensions needing intervention or attention.

Reproduction steps

No clear repro of the issue yet other than running many sessions for extended periods of time and needing to frequently scroll to bottom to see if an instance needs attention despite ensuring all instances are scrolling to bottom at various points in time.

Expected result

Thinking blocks that started when scroll-to-bottom is engaged continue to scroll to bottom throughout.

Actual result

Thinking blocks start will start when scroll-to-bottom is engaged, scroll-to-bottom as expected for a while, but a high percentage of the time will stop scrolling to the bottom before long thinking blocks are complete.

Variations tried (optional)

No response

App Version

3.38.2

API Provider (optional)

Not Applicable / Other

Model Used (optional)

Roo Code Cloud/GPT-5.2 to see lengthy thinking blocks

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

The scroll-to-bottom disengagement during long thinking blocks is caused by a race condition in the scroll event handler. In ChatView.tsx, the onScroll handler checks if the view is near the bottom:

const nearBottom = Math.abs(el.scrollHeight - el.scrollTop - el.clientHeight) < 10
if (!nearBottom) {
    stickyFollowRef.current = false
}

During rapid content streaming (especially long thinking blocks), there can be brief moments where:

1. Content is being added to the DOM
2. The scrollHeight hasn't been fully recalculated yet
3. The scroll event fires and the nearBottom calculation momentarily returns false
4. This sets stickyFollowRef.current = false, disabling auto-scroll
5. The followOutput callback returns false (since both isAtBottom and stickyFollowRef.current are false)
6. Auto-scrolling stops permanently until the user clicks the scroll-to-bottom button

This is more pronounced under high CPU load because timing discrepancies are amplified.

Proposed Fix

1. Create a ref to track streaming state - The current onScroll handler has no dependencies and can't access the isStreaming state. We'll add isStreamingRef to track this.

2. Modify the scroll event handler - During active streaming, do NOT disable stickyFollowRef based on scroll position calculations. The only way to disengage auto-scroll during streaming should be through explicit user actions:

   • Scroll wheel events (already handled by handleWheel)
   • Expanding chat rows (already handled in expandedRows effect)

3. Keep the button visibility logic intact - The setShowScrollToBottom(!nearBottom) call should remain unchanged so the UI stays responsive.

Code Changes

In webview-ui/src/components/chat/ChatView.tsx:

1. Add a ref to track streaming state (around line 156):

const isStreamingRef = useRef(false)

2. Keep the ref in sync with the computed value (after the isStreaming useMemo):

useEffect(() => {
    isStreamingRef.current = isStreaming
}, [isStreaming])

3. Update the scroll handler to check streaming state (lines 1163-1178):

useEffect(() => {
    const el = scrollContainerRef.current
    if (!el) return
    const onScroll = () => {
        const nearBottom = Math.abs(el.scrollHeight - el.scrollTop - el.clientHeight) < 10
        // Only disable sticky follow when NOT streaming
        // During streaming, only explicit user actions (wheel events, row expansion) should disengage
        if (!nearBottom && !isStreamingRef.current) {
            stickyFollowRef.current = false
        }
        setShowScrollToBottom(!nearBottom)
    }
    el.addEventListener("scroll", onScroll, { passive: true })
    return () => el.removeEventListener("scroll", onScroll)
}, [])

This approach ensures that:

• During streaming, auto-scroll continues unless the user explicitly scrolls up
• The scroll-to-bottom button still appears/disappears correctly based on position
• After streaming ends, normal scroll behavior resumes
• Explicit user actions (scroll wheel, row expansion) still disengage auto-scroll as expected

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.