Keep the selection when a drag crosses a custom attachment

[lyubomir-bozhinov]

Fixes #1148.

The bug

Dragging a selection across a mention wiped the entire selection in Firefox. The drag ended with no range at all — nothing highlighted, nothing to copy or replace.

	drag across Hello @Zacharias world
Blink	"Hello \n world", 1 range
Gecko	"", 0 ranges, collapsed

A drag across plain text in the same editor selects normally in Gecko, so the mention is what breaks it.

Why

Gecko will not extend a selection across a contenteditable="false" island unless the island is selectable as a single unit; it abandons the selection instead. Marking custom attachments user-select: all makes them span-able, and the mention's text is included in the selection.

Two other suspects were ruled out first — neither changed the outcome:

• draggable="true" on the attachment (setting it to false made no difference)
• display: inline-flex (inline-block and inline both still failed)

The fix

user-select: all on custom attachments, following the existing @supports pattern in this file.

The rule is scoped to the editor with the lexxy-editor & nesting this file already uses (see the :not(lexxy-editor &) block above). Rendered, read-only Action Text has no contenteditable island and so never hits the Gecko bug — it must keep normal text selection, so the workaround must not reach it.

Inside the editor there is no visual change: before/after screenshots of a selected mention are pixel-identical, and clicking a mention still selects the node as it did before.

Tests

test/browser/tests/prompts/selection_across_mention.test.js, driven with a real mouse drag:

• dragging across a mention selects the surrounding text — fails on Firefox without this change, passes with it
• dragging across plain text still selects it — the control, so a regression in ordinary selection cannot hide behind the first test

Verified on Chromium, Firefox and WebKit. prompts/ and attachments/ are green on Firefox; yarn lint and yarn test are clean.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[Copilot]

Pull request overview

Fixes a Firefox (Gecko) selection bug where dragging a text selection across a contenteditable="false" custom attachment (mentions) collapses the selection to zero ranges by making custom Action Text attachments selectable as a single unit inside the editor.

Changes:

• Add an editor-scoped user-select: all rule for custom Action Text attachments to keep drag-selection intact in Gecko.
• Add a Playwright browser test that performs a real mouse drag across a mention and asserts selection is preserved, plus a plain-text control case.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
test/browser/tests/prompts/selection_across_mention.test.js	Adds a cross-browser regression test for drag-selection spanning a mention attachment.
app/assets/stylesheets/lexxy-content.css	Applies an editor-only user-select: all workaround to custom Action Text attachments to prevent Gecko from dropping the selection.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

app/assets/stylesheets/lexxy-content.css:490

• This nested selector requires a .lexxy-content descendant inside <lexxy-editor> (effectively lexxy-editor :where(.lexxy-content) action-text-attachment…). In the actual editor DOM, <lexxy-editor> itself owns .lexxy-content and its content child is .lexxy-editor__content, so the rule does not match and the Firefox workaround is inactive. Match attachments whose subject is a descendant of the editor instead, or move this rule to a top-level editor selector.

    lexxy-editor & {

[lyubomir-bozhinov]

Copilot's latest pass suppressed a comment claiming the lexxy-editor & rule never matches, and therefore that this fix is inert. Noting here for anyone reading that review: the rule does match, and I checked rather than assumed.

The claim rests on desugaring & by textual concatenation, giving lexxy-editor :where(.lexxy-content) action-text-attachment[…]. That form genuinely would not match — it wants a .lexxy-content descendant of <lexxy-editor>, while the editor element carries the class itself. But per the CSS Nesting spec & resolves to :is(<parent selector list>), so the rule is lexxy-editor :is(:where(.lexxy-content) action-text-attachment[…]). With :is() one element can satisfy both conditions, and <lexxy-editor class="lexxy-content"> is simultaneously the .lexxy-content ancestor and the lexxy-editor ancestor.

Measured in the browser on this branch, with a mention in the editor and the same markup in a plain .lexxy-content read view:

check	result
editor element carries .lexxy-content	true
any descendant carries .lexxy-content	false
matches lexxy-editor :where(.lexxy-content) action-text-attachment	false
matches lexxy-editor :is(:where(.lexxy-content) action-text-attachment)	true
computed user-select, mention in editor	all
computed user-select, mention in read view	none

So the workaround is active where it should be and stays out of the rendered view, which was the scoping requirement. The regression test is consistent with that: reverting only this CSS makes the drag-across-a-mention test fail on Chromium and Firefox, and restoring it makes it pass.

Happy to switch to an explicit top-level editor selector if that reads better to you — it would resolve to the same thing, just without depending on :is() semantics to make the point.