fix: clear text selection on card drag start (#515)

[Chris0Jeky]

Summary

• Cards with selected text are now draggable
• Adds handleDragHandleMouseDown that calls window.getSelection()?.removeAllRanges() on the drag handle's mousedown event
• Adds user-select: none / -webkit-user-select: none CSS to .td-card-drag-handle to prevent the handle itself from being selected
• Closes BUG: Text-selected cards become non-draggable until selection is cleared #515

Root cause

When a user selects text inside a card, the browser prioritises a text-drag over the card's HTML drag. Because the drag handle never cleared the selection, the card became effectively non-draggable until the user manually deselected the text.

Fix

1. @mousedown on the drag handle calls window.getSelection()?.removeAllRanges() immediately, before the browser decides whether to start a text-drag or an element-drag.
2. CSS user-select: none on the handle element prevents the handle icon itself from being selected.

Test plan

• Select text on a card, then grab the drag handle — card moves correctly
• Text can still be selected normally inside card title/description when not dragging
• npm run typecheck passes (verified: clean exit)

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[gemini-code-assist]

Code Review

This pull request addresses issue #515 by clearing active text selections when the card drag handle is clicked, ensuring the browser initiates a card drag instead of a text-drag. It introduces a handleDragHandleMouseDown function and applies user-select: none to the drag handle. The review feedback suggests adding an automated test to verify the selection clearing behavior and recommends including additional vendor prefixes for the user-select CSS property to improve cross-browser compatibility.

[gemini-code-assist]

To prevent future regressions, it would be beneficial to add an automated test case that covers this scenario. You can simulate text selection within the test and then verify that the selection is cleared when mousedown is triggered on the drag handle.

Here's an example of how you could write such a test using vitest and @vue/test-utils:

it('clears text selection on drag handle mousedown', async () => {
  const wrapper = mount(CardItem, {
    props: { card: createCard() },
  });

  const selection = window.getSelection();
  if (!selection) {
    // JSDOM supports getSelection, but good practice to check.
    return;
  }

  // 1. Simulate text selection
  const title = wrapper.get('.td-board-card__title');
  const range = document.createRange();
  range.selectNodeContents(title.element);
  selection.removeAllRanges();
  selection.addRange(range);
  expect(selection.toString()).toBe(wrapper.props().card.title);

  // 2. Trigger mousedown on the drag handle
  await wrapper.get('[data-action=\"drag-card-handle\"]').trigger('mousedown');

  // 3. Assert that the selection was cleared
  expect(selection.toString()).toBe('');
});

This would ensure the fix remains effective as the codebase evolves.

[gemini-code-assist]

For improved cross-browser compatibility, it's best practice to include other vendor prefixes for user-select and list the standard property last. This ensures that browsers use the standard implementation if available, falling back to the prefixed version otherwise.

  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;

[Chris0Jeky]

Adversarial review findings

Reviewed against the full checklist. Six items are clean; one genuine gap was found and fixed.

Items that pass

1. Touch/mobile — The mousedown handler is desktop-only (HTML5 drag API does not fire on touch). However, the underlying drag mechanism (draggable="true" / @dragstart) has never worked on touch, so this is a pre-existing limitation, not a regression introduced by this PR.

2. Drag library conflicts — No SortableJS, vue-draggable, or other drag library is present in package.json. Plain HTML5 drag API only. No conflict possible.

3. user-select: none scope — CSS is scoped (<style scoped>) and the rule is on .td-card-drag-handle only. The card title and description are siblings of the handle inside .td-board-card, not descendants of the handle, so they are unaffected. Users can still select text in title/description normally.

4. mousedown vs dragstart placement — mousedown is the correct hook. It fires before the browser decides whether to start a text-drag or an element-drag. Adding the removeAllRanges call to dragstart instead would be too late.

5. Browser compatibility — user-select (unprefixed) covers all modern browsers. -webkit-user-select is retained for Safari/older Chrome. ms-user-select would only be needed for IE11, which is not a target here.

6. CSS class name — Template applies td-card-drag-handle (line 86); CSS targets .td-card-drag-handle (line 209). They match exactly.

Genuine issue found and fixed

7. Missing test coverage — handleDragHandleMouseDown shipped with no unit test. The existing CardItem.spec.ts had tests for drag guardrails but none covering the new mousedown → removeAllRanges behavior.

Fix applied in commit dad99cc0: added two vitest cases to CardItem.spec.ts in a new CardItem drag handle — text selection clearing describe block:

• verifies removeAllRanges is called once when the drag handle receives mousedown
• verifies no throw when getSelection() returns null (the optional-chain path)

All 5 tests (3 pre-existing + 2 new) pass.