Fix drag gesture triggering on interactive elements inside draggables

[mattgperry]

Summary

• Prevents drag from starting when clicking on interactive elements (input, textarea, select, button, anchor, contenteditable) inside a draggable component
• Allows normal interaction with form elements (focus, text selection) without triggering the parent's drag gesture

Fixes #1674

Test plan

• Added E2E tests for input and textarea inside draggable elements
• Verified existing drag tests still pass (43 tests)
• Test manually: create a draggable with an input inside, clicking on the input should focus it and allow text selection without triggering drag

🤖 Generated with Claude Code

[claude]

Code Review

Thank you for this PR! This is a well-thought-out fix for issue #1674. Here's my detailed review:

✅ Strengths

1. Excellent Test Coverage: Following the CLAUDE.md guidance, you've correctly written comprehensive E2E tests first using Cypress. The tests cover:

   • Input elements inside draggables
   • Textarea elements inside draggables
   • Verification that normal dragging still works on non-interactive areas

2. Consistent Pattern: The fix reuses the existing isElementKeyboardAccessible function that's already used in the press gesture handler (packages/motion-dom/src/gestures/press/index.ts:112), maintaining consistency across the codebase.

3. Logical Implementation: The contenteditable addition to isElementKeyboardAccessible makes sense - contenteditable elements should be treated like text inputs for interaction purposes.

4. Minimal Changes: The fix is surgical and doesn't over-engineer the solution, following the project's preference for simplicity.

🔍 Potential Issues & Suggestions

1. Event Target vs Current Target (Medium Priority)

The code checks event.target to determine if the clicked element is interactive:

\!isElementKeyboardAccessible(event.target as Element)

However, this may not handle all edge cases. Consider:

• What if a user clicks on a <span> or <label> inside an <input>?
• What if there are nested interactive elements?

Recommendation: Consider traversing up the DOM tree to check if any ancestor (up to the draggable element) is keyboard accessible:

function hasKeyboardAccessibleAncestor(
    target: Element, 
    stopAt: Element
): boolean {
    let current: Element | null = target
    while (current && current \!== stopAt) {
        if (isElementKeyboardAccessible(current)) {
            return true
        }
        current = current.parentElement
    }
    return false
}

Then use: \!hasKeyboardAccessibleAncestor(event.target as Element, element)

Test Case: Add a test with an input that has child elements (e.g., <input><span>Text</span></input> isn't valid, but <label><span>Text</span><input /></label> is).

2. Select Element Menu (Low Priority)

The fix prevents drag on <select> elements, but <select> dropdowns can extend beyond the element's bounds. If a user clicks to open the dropdown and the mouse moves while the menu is open, does this trigger a drag on the parent? This might be fine, but worth testing manually.

3. Custom Interactive Elements (Low Priority)

Elements with role="button", role="textbox", etc., are semantically interactive but won't be caught by the current implementation. While this might be acceptable for most use cases, consider documenting this limitation or adding support for ARIA roles if needed.

4. Type Safety (Minor)

The cast event.target as Element assumes event.target is always an Element. While this is generally safe for pointer events on DOM elements, adding a guard could improve robustness:

const target = event.target
if (\!(target instanceof Element)) return
if (drag && dragListener && \!isElementKeyboardAccessible(target)) {
    this.start(event)
}

📝 Code Quality

• ✅ Follows existing code style and conventions
• ✅ No linting issues expected (uses existing patterns)
• ✅ Proper import organization
• ✅ Clear test descriptions and structure

🧪 Test Suggestions

Consider adding these edge case tests:

1. Button inside draggable: Verify buttons don't trigger drag
2. Link (anchor) inside draggable: Verify links remain clickable
3. Select dropdown interaction: Test that opening/closing select menus works correctly
4. Nested interactive elements: Test labels containing inputs
5. ContentEditable element: Since you added this case, add a specific test for it

🎯 Performance & Security

• ✅ No performance concerns - the check is lightweight
• ✅ No security issues identified
• ✅ No unnecessary re-renders or memory leaks

📖 Documentation

Consider adding a JSDoc comment to the isElementKeyboardAccessible function explaining its purpose and the interactive elements it covers, especially since it's now used in multiple gesture contexts.

Summary

This is a solid PR that solves a real usability issue. The main concern is the potential edge case with nested elements. I'd recommend:

1. Must fix: Test manually with labels containing inputs to verify the fix works with nested scenarios
2. Should consider: Add the ancestor traversal logic if nested cases fail
3. Nice to have: Add the additional test cases mentioned above

Great work following the test-first approach from CLAUDE.md! 🎉

[claude]

Code Review Summary

I've reviewed PR #3448 and overall this is a well-implemented fix for issue #1674. The solution is elegant, focused, and follows the repository's best practices. Great work!

✅ Strengths

1. Test-First Approach: Excellent adherence to the repository's testing guidelines! You added comprehensive E2E tests in Cypress before implementing the fix, which aligns perfectly with the CLAUDE.md guidance.

2. Minimal, Focused Change: The fix is precisely targeted - only 3 lines of actual implementation code in VisualElementDragControls.ts to add the check for keyboard-accessible elements.

3. Code Reuse: Smart reuse of the existing isElementKeyboardAccessible function from the press gesture system, which already had the right logic for detecting focusable elements.

4. Comprehensive Test Coverage: The Cypress tests cover all the key scenarios:

   • Input elements don't trigger drag
   • Textarea elements don't trigger drag
   • Non-input areas still allow dragging

5. Export Addition: Properly exported isElementKeyboardAccessible from motion-dom/src/index.ts for use in framer-motion.

6. Documentation Update: Updated CLAUDE.md with the test-first requirement, which will help future contributors.

🔍 Observations & Suggestions

1. Consider <select> and <button> Elements

The isElementKeyboardAccessible function includes BUTTON and SELECT in its focusable elements list (lines 2, 4 in is-keyboard-accessible.ts), but your test page (drag-input-propagation.tsx) only tests <input> and <textarea>.

Suggestion: Consider adding test cases for:

• <select> dropdowns (users should be able to open/interact with dropdowns)
• <button> elements (users should be able to click buttons without triggering drag)
• <a> tags (links should be clickable)
• Elements with contentEditable="true"

This would ensure comprehensive coverage of all interactive elements the fix is supposed to handle.

2. Test Code Quality (Minor)

In drag-input-propagation.ts:21, you have:

.trigger("pointermove", 200, 200, { force: true })

The { force: true } flag is typically used when Cypress detects the element is not visible/actionable. Since this is a large drag movement and might move the pointer outside the input, this is probably correct. However, you might want to verify this doesn't mask any unintended behavior.

3. Edge Case: Nested Interactive Elements

The current implementation checks event.target directly. Consider what happens with nested structures like:

<motion.div drag>
  <label>
    <span>Click me</span>
    <input />
  </label>
</motion.div>

If a user clicks on the <span> inside the label, event.target would be the span, not the input, potentially allowing drag to start. This may or may not be desired behavior - just something to be aware of.

4. Performance Consideration (Minor)

The check happens on every pointerdown event, which is fine. The isElementKeyboardAccessible function is very efficient (Set lookup + 2 property checks), so there's no performance concern here.

🎯 Code Quality Assessment

• Code Style: ✅ Follows repository conventions (interface usage, named exports, strict equality)
• Best Practices: ✅ Excellent adherence to test-first development
• Performance: ✅ No concerns
• Security: ✅ No security issues introduced
• Test Coverage: ✅ Good coverage, could be expanded (see suggestion Initial API (WIP) #1)

📋 Recommendation

Approve with minor suggestions. The core fix is solid and ready to merge. The additional test cases for other interactive elements (<select>, <button>, <a>, contentEditable) would make this even more robust, but they're not blockers.

Great work on following the repository's development practices!

[claude]

Pull Request Review

Summary

This PR fixes issue #1674 by preventing drag gestures from starting when users interact with interactive elements (inputs, textareas, buttons, links, selects, contenteditable) inside draggable components. The solution is elegant and well-tested.

---

✅ Strengths

1. Excellent Test Coverage

• Comprehensive E2E tests covering all interactive element types (input, textarea, button, link, select, checkbox, contenteditable)
• Tests verify both that interactive elements DON'T trigger drag AND that dragging still works on non-interactive areas
• Follows the repository's guidance of writing E2E tests for UI interaction bugs (CLAUDE.md)
• 8 test cases provide thorough coverage of edge cases

2. Clean Implementation

• Minimal code changes (only 11 lines of actual implementation code)
• Reuses existing isElementKeyboardAccessible utility function, extending it appropriately
• Single point of interception in VisualElementDragControls.ts:638 makes the logic easy to understand and maintain
• The solution is framework-agnostic by being implemented in the core gesture layer

3. Good Developer Documentation

• Added guidance to CLAUDE.md about writing tests first (test-driven development)
• Clear PR description with test plan
• Well-commented test file explaining the purpose

---

🔍 Code Quality Observations

Minor Issues

1. Export Addition May Be Unnecessary

// packages/motion-dom/src/index.ts
+export * from "./gestures/press/utils/is-keyboard-accessible"

Issue: This exports isElementKeyboardAccessible from the public API of motion-dom, but it appears to only be used internally.

Recommendation: Consider whether this utility should be part of the public API. If it's only for internal use across packages, you might want to:

• Document it as an internal API (JSDoc with @internal), or
• Export it from a separate internal entry point

2. Missing Edge Case: Nested Interactive Elements

The current implementation checks only event.target, but consider this scenario:

<motion.div drag>
  <label>
    <span>Click me</span>
    <input />
  </label>
</motion.div>

If a user clicks on the <span> inside the <label>, event.target will be the span, not the label or input, and drag will trigger.

Test: The test file includes a checkbox inside a label, which is good! However, the test clicks directly on the checkbox (cy.get("[data-testid='checkbox']").trigger(...)), not on the label text.

Recommendation: Add a test case that clicks on the label text itself (not the input/checkbox) to verify this edge case is handled. You may need to check event.target.closest() or traverse up the DOM tree to find keyboard-accessible ancestors.

3. Test Robustness: Hard-coded Coordinates

cy.get("[data-testid='draggable']")
  .trigger("pointerdown", 5, 5)  // Hard-coded coordinates

Issue: The tests use hard-coded coordinates (5, 5) which assume the element layout. If the test component layout changes, tests could break or pass incorrectly.

Recommendation: While this matches existing test patterns in the codebase (see drag.ts:15), consider using dynamic positioning or at least add comments explaining why these specific coordinates are chosen (e.g., "top-left corner, avoiding all interactive elements").

---

🎯 Functionality Review

Correct Behavior ✅

The implementation correctly:

1. Prevents drag from starting on focusable elements (INPUT, TEXTAREA, SELECT, BUTTON, A)
2. Prevents drag on elements with tabIndex !== -1
3. Prevents drag on contenteditable elements (good catch on adding this to isElementKeyboardAccessible)
4. Maintains backward compatibility - existing drag functionality remains unchanged
5. Works with nested interactive elements (via the checkbox-in-label test)

Potential Concerns

1. Custom Interactive Components

Elements with role="button" or role="textbox" won't be detected by this implementation. While these should probably also have tabIndex, it's not guaranteed.

Example:

<motion.div drag>
  <div role="button" onClick={handleClick}>Custom Button</div>
</motion.div>

Impact: Low - Most properly implemented custom interactive components should have tabIndex for accessibility.

Recommendation: Consider adding a comment documenting this limitation, or extend the check to include common ARIA roles.

2. Performance Consideration

isElementKeyboardAccessible is now called on every pointerdown event on a draggable element. The function is very lightweight (Set lookup + 2 property checks), so performance impact should be negligible.

Verdict: No action needed, but worth monitoring in performance-critical applications with many draggable elements.

---

🔒 Security Review

No security concerns identified. The changes are defensive in nature:

• Read-only checks on DOM element properties
• No user input parsing or sanitization needed
• No new XSS vectors introduced

---

📋 Additional Recommendations

1. Add JSDoc Comments

/**
 * Prevents drag from initiating when interacting with keyboard-accessible
 * elements like inputs, buttons, and links inside a draggable container.
 * This allows users to interact normally with form controls without
 * accidentally triggering drag gestures.
 * 
 * @see https://github.com/motiondivision/motion/issues/1674
 */
const stopPointerListener = addPointerEvent(
  element,
  "pointerdown",
  (event) => {
    // ...
  }
)

2. Consider Adding a Prop for Opt-Out

While the current behavior is sensible as the default, some users might want the old behavior. Consider adding a prop like dragIgnoreInteractive={false} in a future PR if users request it.

3. Test with Real User Interaction (Manual Testing)

Ensure manual testing covers:

• Text selection in inputs/textareas
• Opening select dropdowns
• Clicking buttons
• Following links (with preventDefault)
• Typing in contenteditable elements

The PR description mentions manual testing, which is great! ✅

---

🏁 Conclusion

This is a high-quality PR that solves a real UX problem with a clean, minimal implementation. The test coverage is excellent and the code follows the repository's conventions.

Approval Recommendation: ✅ Approve with Minor Suggestions

The suggestions above are minor enhancements that could be addressed in follow-up PRs if needed. The current implementation is production-ready.

Priority Suggestions:

1. 🔴 High: Verify the nested interactive element edge case (clicking on label text)
2. 🟡 Medium: Add JSDoc comment explaining the behavior
3. 🟢 Low: Consider whether the export in motion-dom/index.ts should be marked as internal

Great work on fixing this long-standing issue! 🎉

[claude]

PR Review: Fix drag gesture triggering on interactive elements

Summary

This PR addresses issue #1674 by preventing drag gestures from starting when users interact with focusable/interactive elements (inputs, textareas, buttons, links, etc.) inside draggable components. The fix is elegant and well-tested.

---

✅ Strengths

1. Excellent test coverage: 8 comprehensive E2E tests covering all interactive element types (input, textarea, button, link, select, checkbox, contenteditable) plus a positive test case
2. Minimal code changes: The fix is surgical - only 3 lines of logic added to the core drag handler
3. Proper reuse: Leverages existing isElementKeyboardAccessible function from the press gesture system, maintaining consistency across gesture handlers
4. Follows TDD: Tests were written first (as evidenced by the PR structure), aligning with the project's CLAUDE.md guidelines
5. Clear documentation: Added important testing guidelines to CLAUDE.md about writing failing tests first

---

🔍 Code Quality Review

VisualElementDragControls.ts (packages/framer-motion/src/gestures/drag/VisualElementDragControls.ts:643-649)

✅ Good: The check is placed at the right level - filtering at event listener attachment time
✅ Good: Uses event.target which correctly identifies the actual clicked element, not the draggable container

is-keyboard-accessible.ts (packages/motion-dom/src/gestures/press/utils/is-keyboard-accessible.ts:13)

✅ Good: Added isContentEditable support
✅ Good: The function name accurately describes what it checks

---

🤔 Potential Concerns & Questions

1. TabIndex edge case - Custom tabIndex values

The current implementation checks tabIndex !== -1. This means:

• ✅ Elements with tabIndex="0" (natural focus order) → blocked ✓
• ✅ Elements with tabIndex="1+" (custom focus order) → blocked ✓
• ✅ Elements with tabIndex="-1" (programmatically focusable) → NOT blocked

Question: Should elements with tabIndex="-1" (programmatically focusable but not tab-reachable) allow drag? This seems like the correct behavior since they're typically used for programmatic focus management rather than user interaction, but worth confirming.

Example: Modal backdrops or hidden panels with tabIndex="-1" for programmatic focus would still allow drag, which is likely desired.

2. Event bubbling consideration

The check uses event.target (the element that was actually clicked), not event.currentTarget (the element with the listener). This is correct, but worth documenting:

<motion.div drag>
  <div>
    <input /> {/* event.target = input, will prevent drag ✓ */}
  </div>
</motion.div>

✅ This is the desired behavior and is correctly implemented.

3. Disabled interactive elements

Elements like <button disabled> or <input disabled> still match the tagName check.

Question: Should disabled interactive elements allow drag?

Current behavior: ❌ Drag prevented on disabled elements
Potential alternative: Allow drag on disabled elements since they can't be interacted with

This might be worth a test case:

<button disabled>Disabled button</button> // Currently prevents drag

4. Form element descendants

The current check doesn't handle labels clicking on their associated inputs:

<motion.div drag>
  <label htmlFor="my-input">Click me</label> {/* Allows drag - is this desired? */}
  <input id="my-input" /> {/* Prevents drag ✓ */}
</motion.div>

Current behavior: Clicking the label text (not the checkbox case which is tested) would trigger drag.
Expected behavior: Might want to prevent drag to avoid interfering with label-to-input focus behavior.

---

🧪 Test Coverage Assessment

Covered scenarios ✅:

• All major interactive element types
• Nested interactive elements (checkbox in label)
• ContentEditable elements
• Positive test case (dragging should still work on non-interactive areas)

Missing test scenarios ⚠️:

1. Disabled elements: <button disabled>, <input disabled>
2. Custom tabIndex: Elements with tabIndex="5" or tabIndex="-1"
3. Label-to-input association: <label htmlFor="..."> clicking
4. Nested draggables: Interactive element inside nested draggables
5. Dynamic content: Elements that become interactive after initial render
6. Shadow DOM: Interactive elements inside shadow DOM (if applicable)

---

🔒 Security Considerations

✅ No security concerns identified

• The change only affects event handling logic
• No user input is processed or stored
• No new XSS vectors introduced
• The Element type cast is safe as it's narrower than EventTarget

---

⚡ Performance Considerations

✅ Performance impact is minimal:

1. Function call overhead: isElementKeyboardAccessible is called on every pointerdown, but:

   • It's a simple O(1) operation (Set lookup + property checks)
   • Only runs when drag && dragListener are true
   • Prevents potentially expensive drag calculations when not needed

2. No memory leaks: No new event listeners or references stored

3. Optimization opportunity: The function is already exported and could be tree-shaken if not used elsewhere

---

📚 Documentation & Code Style

✅ Follows project conventions:

• Uses TypeScript interfaces
• Named exports (no default exports)
• Clear, descriptive names
• Proper import organization

✅ CLAUDE.md update is valuable: The addition about writing failing tests first is a good practice to document

⚠️ Minor suggestion: Consider adding a JSDoc comment to isElementKeyboardAccessible explaining its purpose in both press and drag contexts:

/**
 * Determines if an element is keyboard accessible (focusable/interactive).
 * Used to prevent gesture handlers (press, drag) from interfering with
 * native browser interactions on interactive elements.
 * 
 * @returns true if element is a focusable element (button, input, etc.),
 *          has a non-negative tabIndex, or is contentEditable
 */
export function isElementKeyboardAccessible(element: Element) { ... }

---

🎯 Recommendations

Must-do:

• ✅ No blocking issues - code is production-ready

Should consider:

1. Test disabled elements: Add test case for <button disabled> to verify intended behavior
2. Document tabIndex="-1" behavior: Add a comment explaining why !== -1 is used
3. Add JSDoc: Document the function's dual use in press and drag gestures

Nice-to-have:

1. Add test for custom tabIndex values (tabIndex="5")
2. Consider label-for-input edge case
3. Add test for nested draggables with interactive elements

---

✨ Conclusion

Overall assessment: Excellent PR ⭐⭐⭐⭐⭐

This is a well-crafted fix that solves a long-standing issue (#1674) with minimal code changes and comprehensive testing. The solution is elegant, maintainable, and follows project conventions. The minor concerns raised are edge cases that may or may not need handling depending on product requirements.

Recommendation: ✅ Approve and merge (consider addressing the disabled elements test case first if time permits)

Great work! 🎉

[claude]

Pull Request Review

This PR effectively fixes issue #1674 by preventing drag gestures from starting when users interact with focusable/interactive elements inside draggable containers. The implementation is clean and well-tested.

✅ Strengths

1. Comprehensive Test Coverage

The E2E tests cover all major interactive elements:

• Standard form inputs (input, textarea, select, button)
• Links (<a> tags)
• Nested inputs (checkbox inside label)
• Content-editable elements
• Includes a positive test case verifying drag still works on non-interactive areas

2. Clean Implementation

• Minimal code change in VisualElementDragControls.ts:646 - adds a single condition check
• Properly exports the utility function from motion-dom
• Follows existing code patterns (similar to how it's used in press gestures)

3. Good Documentation

• Updated CLAUDE.md with testing best practices
• Clear test descriptions and comments
• PR description clearly explains the fix

🐛 Potential Issues

1. Missing contenteditable Check (CRITICAL)

The isElementKeyboardAccessible function doesn't check for contenteditable attribute:

// packages/motion-dom/src/gestures/press/utils/is-keyboard-accessible.ts:9
export function isElementKeyboardAccessible(element: Element) {
    return (
        focusableElements.has(element.tagName) ||
        (element as HTMLElement).tabIndex \!== -1
    )
}

While the test includes a contenteditable element (drag-input-propagation.tsx:97), the implementation doesn't actually check for it. The test might be passing due to the tabIndex \!== -1 check if the browser automatically makes contenteditable elements focusable, but this is not guaranteed and could be browser-dependent.

Recommendation: Add explicit contenteditable check:

export function isElementKeyboardAccessible(element: Element) {
    const htmlElement = element as HTMLElement
    return (
        focusableElements.has(element.tagName) ||
        htmlElement.tabIndex \!== -1 ||
        htmlElement.isContentEditable
    )
}

2. Edge Case: Labels Without Interactive Children

The implementation blocks drag on event.target, which means clicking a <label> that doesn't contain an input will allow dragging, but clicking the same label that wraps an input will block it (because the target is the input). This is probably fine, but worth noting for consistency.

3. Disabled Elements

A disabled button/input should arguably allow drag-through since it's not interactive. Consider:

const isDisabled = (element as HTMLButtonElement | HTMLInputElement).disabled
if (\!isDisabled && isElementKeyboardAccessible(event.target as Element))

Though this might be over-engineering - current behavior is reasonable.

📊 Code Quality

Positive

• ✅ Follows repository conventions (uses interface, no default exports)
• ✅ TypeScript types are correct
• ✅ No security concerns (no XSS, injection risks)
• ✅ Minimal performance impact (simple Set lookup + property checks)
• ✅ No breaking changes to public API

Minor Suggestions

• Consider adding JSDoc comments to isElementKeyboardAccessible explaining what makes an element "keyboard accessible"
• The function name is accurate for press gestures but slightly misleading here - it's really checking "is this an interactive element" rather than keyboard accessibility per se

🧪 Testing

Coverage: Excellent

• 8 comprehensive E2E tests using Cypress
• Tests verify both negative cases (drag blocked) and positive case (drag works)
• Real user interactions tested (pointerdown, pointermove, pointerup)

Suggestions

• Add a test for disabled interactive elements (<button disabled>) to document expected behavior
• Add a test for contenteditable="false" to verify it doesn't block drag
• Consider testing contenteditable on a span/div with both true and false values explicitly

🎯 Recommendation

Approve with minor fix required: Fix the contenteditable detection issue before merging. The current implementation may work in some browsers but is not guaranteed to be reliable.

The overall approach is sound and this is a valuable fix for a long-standing issue. Great work on the comprehensive test coverage!

---

Review generated using repository conventions from CLAUDE.md

[claude]

Code Review - PR #3448

This PR fixes a long-standing issue (#1674) where interactive elements inside draggable components would trigger drag gestures, preventing normal interaction. Overall, this is a well-implemented fix with excellent test coverage. Here's my detailed review:

---

✅ Strengths

1. Test-Driven Development

• Follows the repository's best practice of writing tests first (even updated CLAUDE.md to emphasize this)
• Comprehensive E2E test coverage with 8 test cases covering all interactive element types
• Tests verify both the fix (interactive elements don't trigger drag) AND that normal drag still works

2. Minimal, Focused Implementation

• Clean, surgical fix in VisualElementDragControls.ts:650 - single conditional check
• Renamed focusableElements to interactiveElements for better semantic clarity
• Good documentation explaining WHY the function was renamed (packages/motion-dom/src/gestures/press/utils/is-keyboard-accessible.ts:9-16)

3. Proper Scope

• Correctly identifies interactive elements: input, textarea, select, button, anchor, contenteditable
• Smart decision to NOT use tabIndex !== -1 check (which would break motion elements with tap handlers)

---

🔍 Code Quality Observations

1. Function Name vs Implementation Mismatch

The function isElementKeyboardAccessible() was renamed in purpose but not in name:

// packages/motion-dom/src/gestures/press/utils/is-keyboard-accessible.ts:17-22
export function isElementKeyboardAccessible(element: Element) {
    return (
        interactiveElements.has(element.tagName) ||
        (element as HTMLElement).isContentEditable === true
    )
}

Suggestion: Consider renaming to isInteractiveElement() or shouldPreventDrag() to better reflect its purpose. The current name suggests it's checking keyboard accessibility, but it's actually checking if drag should be prevented.

2. Missing Edge Cases

The implementation doesn't handle:

• Nested elements: What if a <span> inside a <button> is clicked? The event.target would be the span, not the button

  Suggested fix: Walk up the DOM tree to check if ANY parent (up to the draggable) is interactive:

  function isInteractiveElement(element: Element, stopAt?: Element): boolean {
      let current: Element | null = element
      while (current && current !== stopAt) {
          if (interactiveElements.has(current.tagName) || 
              (current as HTMLElement).isContentEditable === true) {
              return true
          }
          current = current.parentElement
      }
      return false
  }

• Disabled interactive elements: Should <button disabled> still prevent drag? Current implementation would prevent it, which might be undesirable.

3. Type Safety

packages/framer-motion/src/gestures/drag/VisualElementDragControls.ts:650:

!isElementKeyboardAccessible(event.target as Element)

The event.target assertion is reasonable, but could be safer:

!isElementKeyboardAccessible(event.target as Element | null ?? event.currentTarget as Element)

---

🎯 Test Coverage

Excellent coverage for the happy path, but consider adding:

1. Nested element test: Click on <span> inside <button> inside draggable
2. Disabled element test: Click on <button disabled> - should it drag or not?
3. Input with text selection: The original issue mentioned text selection - while the test includes inputs, it doesn't explicitly verify text selection works
4. Edge of interactive element: What happens when clicking exactly on the border between input and draggable background?

---

⚠️ Potential Issues

1. Event Propagation Concern

The fix works at the pointerdown event level in the drag controls. If an interactive element calls event.stopPropagation(), this should still work correctly. However, it's worth verifying that:

• Custom interactive components with their own pointer handlers don't break
• Libraries that wrap form elements (like React Select) work correctly

2. Missing LABEL Element

The test includes a checkbox inside a label, but notice that LABEL is not in the interactiveElements Set. This means clicking directly on label text (not the checkbox) might still prevent drag, which could be unexpected. Consider adding LABEL to the Set if this behavior is desired.

---

🔒 Security Considerations

No security concerns identified. The change is purely behavioral and doesn't introduce XSS, injection, or other vulnerabilities.

---

⚡ Performance Considerations

• Set lookup (interactiveElements.has()) is O(1) - excellent
• Property access for isContentEditable is cheap
• No performance concerns - the check happens once per pointerdown event

---

📋 Summary

Recommendation: ✅ Approve with minor suggestions

This is a solid fix for a UX issue. The implementation is clean, well-tested, and follows repository conventions. My suggestions are mostly about edge cases and naming clarity.

Priority improvements:

1. Handle nested elements (e.g., <span> inside <button>)
2. Consider renaming isElementKeyboardAccessible to better reflect its purpose

Nice-to-haves:
3. Add edge case tests (nested elements, disabled elements)
4. Consider whether LABEL should be in the interactive elements Set
5. Clarify expected behavior for disabled interactive elements in documentation

Great work overall! 🎉