fix: allow users to exit auto-scroll while a response is streaming

[angelplusultra]

Pull Request Type

• ✨ feat (New feature)
• 🐛 fix (Bug fix)
• ♻️ refactor (Code refactoring without changing behavior)
• 💄 style (UI style changes)
• 🔨 chore (Build, CI, maintenance)
• 📝 docs (Documentation updates)

Relevant Issues

resolves #5846

Description

While a response is streaming, users could not scroll up to read earlier messages, the chat history kept snapping back to the bottom on every token, forcing them to "fight" the viewport.

Root cause: the auto-follow effect in ChatHistory ran scrollToBottom on every history change whenever a stream was active (isAtBottom || isStreaming). The only opt-out was isUserScrolling, which is set by the onScroll handler — but that handler is debounced 50ms and skips events flagged as programmatic. During streaming, the per-token programmatic scrolls consistently won that race: by the time the debounced handler ran, the viewport had already been yanked back to the bottom, so the user's upward scroll was never registered.

Fix:

• Auto-follow now only engages when the viewport is actually at the bottom (!isUserScrolling && isAtBottom) — streaming alone no longer forces it.
• Added onWheel / onTouchStart + onTouchMove handlers that set isUserScrolling immediately on upward movement. Unlike scroll events, wheel/touch events are never fired by programmatic scrollTo(), so this opt-out cannot be swallowed by the streaming race.
• Sending a new prompt still snaps to the bottom and re-enables auto-follow (detected via the appended pending assistant reply), preserving the previous on-send behavior that the removed isStreaming clause provided.

Resulting behavior:

1. At the bottom, the view follows the tail of the stream as before.
2. Scrolling up (wheel, touch, or scrollbar drag) immediately stops auto-follow; the user can read freely mid-stream.
3. Auto-follow resumes when the user scrolls back to the bottom, clicks the scroll-to-bottom arrow, or sends a new prompt.

Visuals (if applicable)

Additional Information

Developer Validations

• I ran yarn lint from the root of the repo & committed changes
• Relevant documentation has been updated (if applicable)
• I have tested my code functionality
• Docker build succeeds locally

[shatfield4]

After testing this out, the behavior does not feel natural. When sending another chat after a historical chat, the view is not scrolling to the bottom of the screen but seems to choose a certain point somewhere in the middle of the conversation.

• What should happen here, is on message sent by user -> scroll to bottom and lock into auto scroll unless the user scrolls out of it.

Also something else I noticed is that the scroll to bottom button no longer works for snapping to the autoscroll.

• What should happen is that, if the user clicks the scroll to bottom button as the chats is streaming -> it should snap to the bottom and stay locked into autoscroll.

[angelplusultra]

@shatfield4 I pushed a fix to address your behavior concerns acaf320. Let me know if its working for you. Its pretty ugly though. It makes me wonder if this auto scroll feature is really worth it, do people really want this? Seems like people just complain about it and want autoscroll off and would prefer to just read at their own pace.

[shatfield4]

So this functions just as I was imagining but the code is very hard to follow.

I think we should remove the autoscroll since this is a big complaint we have with many users.

What we can do is just scroll into view a new message being sent but get rid of autoscroll completely. This will allow users to keep reading the message as it streams from top to bottom since autoscroll makes it almost impossible to read as streaming is happening.

Removing the autoscroll should prevent this hard to read code with all these refs and conditional scrolling logic.

(I have tried many times to get this exact feature to work but could never keep the code clean)

@timothycarambat thoughts on this?

[angelplusultra]

So this functions just as I was imagining but the code is very hard to follow.

I think we should remove the autoscroll since this is a big complaint we have with many users.

What we can do is just scroll into view a new message being sent but get rid of autoscroll completely. This will allow users to keep reading the message as it streams from top to bottom since autoscroll makes it almost impossible to read as streaming is happening.

Removing the autoscroll should prevent this hard to read code with all these refs and conditional scrolling logic.

(I have tried many times to get this exact feature to work but could never keep the code clean)

@timothycarambat thoughts on this?

Definitely agree. I think this feature could be removed entirely, with the chat only scrolling to the bottom in two cases:

• When the user sends a message
• When the user clicks the down-arrow button (or via keybinding CMD + ArrowDown)

During an active stream, users should remain in control of scrolling so they can read at their own pace.