fix(message-list): re-pin the chat to the bottom when the content reflows - #251
Closed
vladimirfilosof wants to merge 1 commit into
Closed
vladimirfilosof wants to merge 1 commit into
vladimirfilosof wants to merge 1 commit into
Conversation
…lows The stick-to-bottom ResizeObserver watched only the scroll container's own box. A re-layout that changes the content height without touching that box - the messages re-wrap, `scrollHeight` changes, the browser keeps `scrollTop` - left the list somewhere in the middle of the history with nothing to bring it back: `scroll` never fires, because `scrollTop` itself did not move. iOS Safari does exactly that while the system snapshots the page for a screenshot, so taking one from the bottom of a chat scrolled the feed back into the middle of the conversation and kept it there. Observe the container's children as well, since they span the whole scrollable content. Only the difference is (un)observed, so an already observed child does not re-deliver its size and re-pin the list on every DOM mutation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
🚀 Prerelease version published! Install this PR version: npm i --save-dev @gravity-ui/aikit@2.20.2-beta.de6d28351afafadd45e672108ecf935b8e837979.0 |
|
Preview is ready. |
Contributor
|
🎭 Component Tests Report is ready. |
Contributor
Author
|
Closing: the console-side ticket behind this fix was dropped from the sprint. The analysis and tests stay on the branch if we come back to it. |
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
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.
The stick-to-bottom
ResizeObserverinuseSmartScrollwatched only the scroll container's own box. A re-layout that changes the content height without touching that box — the messages re-wrap,scrollHeightchanges, the browser keepsscrollTop— left the list somewhere in the middle of the history with nothing to bring it back:scrollnever fires, becausescrollTopitself did not move. iOS Safari does exactly that while the system snapshots the page for a screenshot, so taking one from the bottom of a chat scrolled the feed back into the middle of the conversation and kept it there.The container's children are now observed as well, since they span the whole scrollable content. Only the difference is (un)observed, so an already observed child does not re-deliver its size and re-pin the list on every DOM mutation. A user who scrolled up is unaffected — the existing
userScrolledUpguard still gates every re-pin. Covered by unit tests: four of the six fail without the change.Console: CLOUDFRONT-62539
🤖 Generated with Claude Code