timeline: fix auto-scroll undershooting on tall messages#2661
Open
amaanq wants to merge 1 commit intocinnyapp:devfrom
Open
timeline: fix auto-scroll undershooting on tall messages#2661amaanq wants to merge 1 commit intocinnyapp:devfrom
amaanq wants to merge 1 commit intocinnyapp:devfrom
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
Author
|
I have read the CLA Document and I hereby sign the CLA |
ajbura
added a commit
to cinnyapp/cla
that referenced
this pull request
Feb 18, 2026
fdd8af4 to
c862128
Compare
c862128 to
9561851
Compare
9561851 to
ce87b46
Compare
When a tall message (a sticker, a long text block) arrives in an active
room, `useLiveEventArrive` fires and triggers `scrollToBottom(scrollEl,
'smooth')` from a layout effect. But reactions and read receipts from
other participants fire the same handler milliseconds later, and each
`scrollTo({behavior: 'smooth'})` call cancels the inflight CSS
animation and restarts from wherever the viewport has reached, usually
only a few pixels further. The scroll never converges, leaving the new
message partially off-screen.
This commit replaces the native smooth scroll with a
`requestAnimationFrame` loop that reads `scrollHeight - offsetHeight`
each frame and advances `scrollTop` by 20% of the remaining distance
(~230 ms to 95% at 60 fps). Subsequent live events are no-ops because
the running loop already chases the live bottom. `wheel` and
`touchstart` listeners cancel the animation so back-scrolling is
unaffected, and `cancelSmoothScroll` clears state for instant scrolls
on room switches.
Fixes cinnyapp#2259.
ce87b46 to
4d08f47
Compare
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.
Description
When a tall message (a sticker, a long text block) arrives in an active
room,
useLiveEventArrivefires and triggersscrollToBottom(scrollEl, 'smooth')from a layout effect. But reactions and read receipts fromother participants fire the same handler milliseconds later, and each
scrollTo({behavior: 'smooth'})call cancels the inflight CSSanimation and restarts from wherever the viewport has reached, usually
only a few pixels further. The scroll never converges, leaving the new
message partially off-screen.
This commit replaces the native smooth scroll with a
requestAnimationFrameloop that readsscrollHeight - offsetHeighteach frame and advances
scrollTopby 20% of the remaining distance(~230 ms to 95% at 60 fps). Subsequent live events are no-ops because
the running loop already chases the live bottom.
wheelandtouchstartlisteners cancel the animation so back-scrolling isunaffected, and
cancelSmoothScrollclears state for instant scrollson room switches.
Type of change
Checklist: