Repository navigation
fix(web): a selection in the chat survives the list moving its row - #733
Merged
Merged
Conversation
The chat list keeps its rows' elements in order by moving them, and a scroll can set that off. Moving an element collapses every live range inside it: the reader's selection disappeared, and the Copy / Add note actions lost their place in the text and stayed hidden, with no event to tell anyone. Row heights decide when the list moves rows, so this showed up on Linux (and as the flaky "keeps the actions beside the selected text as the list scrolls" test on CI). The actions now watch for their row's element leaving its parent, find the text again from its offsets, and give back a selection the move collapsed (not one the reader changed; a note in progress keeps its own highlight and focus). A new test moves the row by hand and fails without the fix every time.
…a move after an edit Review follow-ups. The selection is given back only while the page's caret still sits where the move collapsed it, so a click elsewhere in the same moment stays the reader's. The observed message body is kept apart from the cached range, so an edit inside the message just before a move no longer hides the move. The test covers an edit with a move, and a click right after one.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
… parent The list moving other rows shifts the caret's offset there, so matching the offset too refused to give the selection back (the new test failed once on CI). A click into any text puts the caret elsewhere, so it still stays the reader's.
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 31, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 31, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 31, 2026
This branch was previously deployed
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.
"keeps the actions beside the selected text as the list scrolls" kept failing on CI after #731 gave it longer waits. #731 treated it as slowness; it wasn't. This is a real bug readers can hit.
What happens. The chat list (
@legendapp/list) keeps its rows' elements in DOM order by moving them, and a scroll can set that off. Moving an element collapses every live range inside it, including the reader's selection and the selection popover's ownRange, and no event fires. The selection vanished, and the Copy / Add note actions stayed mounted but hidden for good, even with the text back in view. Row heights decide when the list moves rows, so it showed on Linux CI and not on the Mac.Evidence. Diagnostic runs on CI (a throwaway branch run with
workflow_dispatch, no PR) logged the selection and DOM changes per step. The failing runs show the row element of message 51 removed and re-added under its parent during a scroll. The page selection then sits collapsed at that parent (rangeCount: 1,isCollapsed: true), and the popover ishiddenwhile the word is in view.Fix.
TranscriptSelectionPopoverwatches the timeline for its message body's row leaving its parent. It then finds the text again from its offsets and, in actions mode, gives back the selection the move collapsed. It does that only while the caret still sits exactly where the move left it, so a click elsewhere stays the reader's. A note keeps its own highlight and focus. The watched body is kept apart from the cached range, so an edit inside the message just before a move can't hide the move. These two guards came from a review.Tests. A new real-list test moves the row with
moveBefore:On CI, the flaky test passed 15/15 repeats with the fix; two of four diagnostic runs failed without it. Locally:
vp fmt,vp lint, typecheck, and the full browser suite pass.