Chat text selection clears and reappears on different messages while manually scrolling

[01-1]

What happened

In the Linux desktop app, I tried to select multiple chat messages by dragging from a message near “test 12” toward the bottom of the conversation. I kept the left mouse button held throughout and manually scrolled. The selection developed gaps: message bodies between highlighted messages—including my “test 45” message—were not highlighted. It then cleared entirely, and later highlighted different messages while the same drag continued. This makes selecting and copying a long span of conversation unreliable.

Diagnosis

The v0.0.42 chat timeline renders messages with LegendList, a virtualized list. Its scroll handler does not explicitly clear the browser selection. The citation selection observer dismisses its own toolbar on scroll, but also does not directly call removeAllRanges() on this path. A likely explanation is that scrolling replaces or unmounts rows containing the native selection’s DOM endpoints, causing the browser selection to collapse or shift. This is a hypothesis based on source and the recording, not a confirmed root cause.

Steps to reproduce

1. Open a desktop-app conversation with enough alternating user and assistant messages to scroll.
2. Press and hold the left mouse button on text near an earlier message (in this case, “test 12”).
3. Drag to select across multiple messages. Keep the button held.
4. Manually scroll toward later messages while continuing the drag.
5. Observe that intervening message bodies can remain unhighlighted; the selection can clear entirely and later reappear on different text.

Version

T3 Code 0.0.42 (v0.0.42, commit 719a76ca1dbf5490f1aa33ffb9966301e02be9a9).

Environment

Linux x64, Fedora kernel 7.2.5-200.fc44.x86_64; T3 Code desktop app. Local T3 server was running during triage. Whether the desktop app was connected to that local server or a remote one was not established. Node v26.8.2 was used for npx t3 triage.

Evidence

User-provided 19-second screen recording and screenshots show one continuous held-click selection changing during manual scroll. One screenshot shows no highlighted text; subsequent screenshots show highlighting on different messages. The message bodies and timestamps are selected inconsistently, including gaps around “test 45.” The recording and screenshots need to be attached by the user after issue creation. No server logs were needed to establish this UI symptom, and none were reviewed.

Relevant source: MessagesTimeline.tsx and selectionActions.ts.

Related issues

No matching issue found in searches for chat text selection clearing or changing during scroll. Existing terminal-selection and mobile text-selection issues concern different surfaces.

Fix applied or workaround

None. Selecting and copying shorter spans without scrolling may avoid the trigger, but was not verified.

Filed by

Codex (GPT-5), via npx t3 triage.

[juliusmarminge]

Triage

Verdict: Valid bug. Keep open.

The scroll handlers are not clearing the selection. The chat timeline is a virtualized LegendList, and a drag that scrolls unmounts and reorders the nodes the browser selection is attached to. That matches gaps, a full clear, and a highlight that lands on different messages while the button is still down.

Area is apps/web. The Linux desktop app is this web UI in Electron. The same timeline is what the hosted site renders. Native mobile chat is a different surface.

Checked on main at 371b52d9. The reported v0.0.42 (719a76ca) already mounts the timeline the same way, and nothing since then preserves a selection across scroll. The recording and screenshots are not attached on the issue, so the pixels were not rechecked. The code path is enough.

What happens

The timeline list does not opt into recycling and does not set a draw distance. @legendapp/list 3.3.5 then defaults recycleItems to false and drawDistance to 250.

          <LegendList<MessagesTimelineRow>
            ref={listRef}
            data={rows}
            extraData={`${listIdentityKey}:${rows.length}`}
            keyExtractor={keyExtractor}
            getItemType={getItemType}
            renderItem={renderItem}
            estimatedItemSize={90}

onScroll={handleScroll} only updates the scroll anchor, the at-end flag, and the minimap. It never touches window.getSelection().

Rows are absolutely positioned (top: 0 plus a per-row top). On web, LegendList keeps a container pool and sorts those containers into index order only 500ms after the last position change (useDOMOrder in 3.3.5). Until that timer fires, DOM order is not visual order. A native selection is a DOM range, so the highlight does not follow the pixels under the cursor. Visually intervening message bodies stay dark, and text that is only adjacent in the DOM lights up somewhere else.

Leaving the viewport plus the 250px buffer drops the container (containerItemKey becomes undefined and the slot renders nothing). Short “test N” rows are well under the 90px estimate, so a manual scroll from “test 12” unmounts that anchor quickly. Chromium then drops or relocates the range. The button is still down, so the next move starts a new range on whatever row is now under the pointer.

The citation toolbar observer does dismiss on scroll, and it does not call removeAllRanges(). That only hides the Cite button. removeAllRanges() in this path runs when the user actually cites.

  const onScroll = () => {
    cancelPending();
    // Autoscroll during a drag must not cancel that gesture's eventual release.
    if (!pointerDown) {
      pointer = null;
      dismissed = true;
    }
    onDismiss("cancel");
  };

user-select: none on tool-row headers, turn folds, and timestamps can also leave unhighlighted chrome between messages. That does not move a highlight onto a different message, and it does not explain a user message body such as “test 45” staying unselected while neighbors are highlighted.

Our LegendList patch reorders containers with Element.moveBefore so a reorder does not restart row state. Electron 44 has that API. The reorder still waits until scrolling has been idle for 500ms, and it does not keep an off-screen anchor mounted.

Not the same issue

• feat(web): faster drag autoscroll and richer terminal selection #7305, fix(web): make terminal selection actions reliable #6555, and fix(web): copy terminal selection with Ctrl+Insert #8541 are terminal selection and terminal drag-autoscroll.
• feat(web): copy chat and terminal selections automatically, Herdr-style #9409 would auto-copy an existing chat or terminal selection. It does not keep the timeline selection intact while scrolling.
• fix(web): copy code block selections without markdown #9175 is copying a code block without markdown.
• fix(swift-ios): enable granular text selection #6110, feat(mobile): make chat text selectable on Android #8779, and fix(swift-ios): select across response blocks and copy as Markdown #11297 are native iOS and Android text selection.
• fix(web): allow text selection when renaming threads #12935 is selecting the thread title while renaming.

No open issue or PR covers chat text selection breaking while the timeline scrolls.

Next step

For the life of a primary-button drag inside the timeline, keep every row from the anchor through the pointer mounted, and do not reorder list containers until mouseup. Scroll must not clear the selection. A short drag that never scrolls should keep working, including Cite on an assistant span.

Repro: a thread of many short alternating user and assistant messages, press on an early message, hold, and scroll with the wheel and the scrollbar toward the bottom. The highlight should stay a single continuous span of the messages the pointer passed through.

[01-1]

Screencast.From.2026-09-21.15-52-05.0.00.-.0.18.7.mp4

Images are in reverse chronological order i think? Not

[01-1]

usage limit might have something to do with it, not sure