Repository navigation
fix(chat): release the bottom lock as soon as the user scrolls up - #899
Merged
xintaofei merged 2 commits intoOct 9, 2026
Merged
Conversation
Scrolling a transcript while a reply streams (or while virtua is still measuring rows) could pull the view back to the bottom, on desktop and on mobile. use-stick-to-bottom only learns about an escape two ways. Its wheel listener escapes only when the nearest overflow:auto ancestor of the event target is the viewport, so a wheel over a code block, table or tool output never escapes. Its scroll listener drops every scroll event that lands while a content resize is in flight, and streaming plus virtua's row measurement keep one in flight almost constantly, so touch, scrollbar and keyboard scrolls are dropped too. The lock stays engaged while the user reads history, and the next content growth or viewport resize scrolls them back down. Read the intent from the input instead: an upward wheel not taken by a nested scroller, a finger dragging the transcript down, an upward scroll key on the focused viewport, or an upward scrollbar drag now release the lock through the library's stopScroll. Following the stream while pinned, the scroll-to-bottom button and jump actions are unchanged.
… scrollbars A mostly sideways wheel or touch pan across a code block or table drifts a few pixels vertically. The escape listener released the lock on that drift even though the horizontal scroller took the gesture and the transcript never moved, so the streaming reply stopped being followed. A wheel whose horizontal delta dominates is now ignored, and a touch settles its axis once, when it first travels past the slop. The scrollbar-drag detector looked for a press outside the viewport's client box. An overlay scrollbar (the macOS default) takes no layout space, so a press on it never matched. A primary press whose target is the viewport element itself now counts as a scrollbar press, and a press on the transcript ends a drag whose release never reached the page.
Collaborator
|
codeg work task |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scrolling a conversation while a reply streams, or while rows are still being measured, can pull the view back to the bottom. It happens on desktop and on the mobile web UI.
Cause:
use-stick-to-bottomonly learns that the user left the bottom in two ways, and neither works reliably in this transcript.overflow: autoancestor of the event target is the viewport. A wheel over a code block, table, or tool output therefore never escapes.The lock stays engaged while the user reads history, and the next content growth or viewport resize scrolls them back down.
Fix: a small listener next to
StickThroughViewportResizereads the user's intent from the input and calls the library'sstopScroll(). It responds to an upward wheel that no nested scroller takes, a finger dragging the transcript down, an upward scroll key on the focused viewport, and an upward drag of the native scrollbar. It does nothing when the lock is already released, during anignoreEscapesscroll, or when the content fits without scrolling. Following the stream while pinned, the scroll-to-bottom button, and the jump actions are unchanged.Tests: added cases to
message-thread.test.tsxfor each escape path and for each case that must leave the lock alone.Checks:
pnpm lint .,tsc --noEmit, and themessage-threadtests pass. Full-suite failures on my machine were 5-second timeouts in unrelated files, which pass when run on their own.