Repository navigation
[Bug] Scope message selection to the active conversation #4077
Description
In the macOS desktop app, native text selection can include content outside the user's intended scope:
- In split view, dragging from channel content into a thread selects both channel and thread content.
- Dragging across a message can select hover quick-reaction emojis and inline reaction pills.
- Popup/overlay content can also participate in selection.
Steps to reproduce
- Open a channel with a threaded message.
- Open the thread in split view.
- Drag-select from a channel message into a thread reply.
- Hover a message and drag-select across its action area.
- Repeat on a message with reaction pills.
Expected behavior
- Channel selection remains inside the channel.
- Thread selection remains inside the thread.
- Message text remains copyable.
- Hover action bars, quick reactions, reaction pills, emoji pickers, reaction popovers, and other interactive overlays are excluded.
- Timestamps and ordinary message metadata may remain selectable.
Version and platform
- Buzz desktop source/config version:
0.5.3 - Source commit:
b1b283cd4 - macOS
26.6(build25G5065a), Apple Siliconarm64
Logs / additional context
Current selection behavior example:
Reacted by Chukwuebuka (Gaus Octavio )
Activity
fix(desktop): keep hover action bar & reaction pills out of text sele…
iroiro147 commentedon Aug 1, 2026
PR #4105 addresses the chrome-contamination half of this issue.
select-none/user-selecton any interactive message chrome — the hover action bar, quick-reaction buttons, reaction pills, and inline add-reaction trigger were all selection-transparent, so a native macOS drag-select swept them up along with message text.select-noneto the two interaction roots —MessageActionBar(desktop/src/features/messages/ui/MessageActionBar.tsx:438) andMessageReactions(desktop/src/features/messages/ui/MessageReactions.tsx:247).user-select: nonepropagates to children, so quick reactions, the more-actions menu, reaction pills, the inline picker trigger, and the emoji-picker popover are all excluded.user-select: containis not universally supported). Suggest evaluating a follow-up based on real-world reports after this lands.tsc --noEmitclean;build:e2eclean; reaction-order / inbox-reactions playwright specs fail identically on unmodifiedmain(pre-existing env flake, unrelated to this change). Manual macOS reproduction would confirm drag-select now stops at the chrome boundary.iroiro147 commentedon Aug 2, 2026
Fixed in #4272.
Root cause: the conversation split view never scoped native drag-selections, so a selection starting in one pane could cross into sibling panes and pull in hover chrome (action bars, quick reactions, reaction pills, emoji pickers, popovers) along the way.
The fix:
data-selection-panemarker.data-selection-exclude+select-none.useConversationSelectionScopehook on the shared conversation root listens forselectionchange; once a drag is anchored inside a pane, the escaping focus end is clamped back to the pane boundary — so channel selection stays in the channel, thread selection stays in the thread.palmentropyc commentedon Nov 11, 2026
Still reproducible on macOS Desktop v0.5.28: copying a few messages pastes the quick-reaction emojis (👍 😂 ❤️) after every message, plus "Copy code block" and the "NEW" divider, with extra blank lines in between. #4105 looks like it would fix the main part of this. Could someone take a look at it?