taye / taye/interact.js

dragstart prevention does not work within shadow dom

Open
#1,065 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
12.9k
Forks
804
PR merge metrics
No merged PRs in 30d

Description

In install, the dragstart event is silenced via this:

  scope.interactions.docEvents.push({
    type: 'dragstart',
    listener(event) {
      for (const interaction of scope.interactions.list) {
        if (interaction.element && (interaction.element === event.target || nodeContains(interaction.element, event.target))) {
          interaction.interactable.checkAndPreventDefault(event);
          return;
        }
      }
    }
  });

However, if a draggable is added to an element inside of a web component's shadow dom, the event's target will be the web component itself, which will fail the nodeContains check. Then, the browser's drag behavior will continue and emit a pointercancel event, effectively immediately canceling the draggable right after it starts.

Ideally draggable.js should attach the listener to the element itself, which will have access to the internals for closed shadow dom components. An easier fix which only works for open shadow doms would be to check the first element of the composedPath to get the "real" element, but this will only work with open shadow doms.

As a workaround, you can manually implement your own drag cancellations on the draggable elements.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the install logic in draggable.js and inspect the dragstart listener's target handling for elements inside shadow DOM. Compare the current nodeContains check with the composedPath behavior described in the issue, then verify that dragging a shadow-DOM element is no longer immediately canceled by a pointercancel event.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.