React-dnd: Problems with inputs and textareas inside of draggable component

Created on 2 Jun 2015  ·  17Comments  ·  Source: react-dnd/react-dnd

I investigate some problems when placing <input> and <textarea> elements inside of draggable component,

  1. cmd+A or Ctrl+A shortcuts doesn't work for input or textarea (but selecting text with Shift + Arrows still works)
  2. Attempt to select input or textarea content with touchpad/mouse starts dragging parent element

My draggable component looks like,

draggable component

bug

Most helpful comment

Elements with contentEditable set inside a draggable parent container wouldn't allow me to select text or interact with them in any way. After some digging, I found this bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=170139

It appears Chrome has since fixed the issue. Safari's behavior can be fixed in the meantime with CSS:

.contenteditable-element {
  user-select: text;
}

All 17 comments

This is caused by the registration of the selectstart event, which is apparently only needed for IE compatibility.
If like me you don't need IE compatibility, here was my quick fix that may work for you :
https://github.com/dperetti/react-dnd/commit/06f74ef97e07a9a24c10eab8593f3e2121d4f2ed

Thanks for reporting! I'm glad to accept a PR fixing this.

I have two requirements:

  • It needs to still have that IE fix.
  • Please verify whether preventDefault() is needed for the other browsers. I think it prevents the text selection of whatever you tried to drag. If it indeed helps prevent unwanted selection in other browsers, you might want to surround e.preventDefault() with some check a la e.target.tagName !== 'input' (but a smarter one).

Same bug with <div contentEditable={isEditing} />.
Also I can't edit it. Ctrl+A and Shift + Arrows doesn't work.

In the next three weeks I'm going to be busy and I don't have the time for fixing this.
As I said I'm happy to accept a PR with a fix as described in https://github.com/gaearon/react-dnd/issues/178#issuecomment-108110202.

Was looking into this. If I comment out the entire handleSelectStart function's body, everything works as expected. Tested this in IE11 and seems to be good there, too.

@gaearon do you know if there's a specific use case or setup for why the event needs to be handled at all? IE10? Different setup from textarea/input in a draggable node? I don't get text selection issues, and I wonder if CSS user-select works around this over preventDefault if necessary.

The original issue was https://github.com/gaearon/react-dnd/issues/128.
If you can prepare a PR that fixes the problem, but also keeps https://github.com/gaearon/react-dnd/issues/128 working, that would be a huge help.

Will see if I can look into it. Need to figure out a way to set up a simple test case for IE9.

I think sortable-simple example failed on IE9 before #128 was fixed.

@gaearon Yeah that was a good example to use, thanks. A few notes:

  1. No other browsers (tested latest Chrome, Safari, FF, and IE 11) seem to care about this. The event doesn't need to be handled whatsoever.
  2. IE9 only appears to only _need_ the e.target.dragDrop() call. Disabling the text selection can be done by creating a handle that covers the entire draggable, wrapping the draggable node in connectDragPreview and the handle in connectDragSource. While this may sound nasty, AFAIK you're not officially supporting IE9 so is that a reasonable workaround, especially when other problems are likely to arise in that browser?
  3. Point number two is also useful anyway in the case that you have a text input within the draggable. Users can't select text by dragging their mice if connectDragSource is applied the the whole node (it ends up dragging the node instead of selecting text), however applying to an invisible handle that is the size of the whole node works very nicely.

Unsure how you want to handle this. Without resorting to UA checking, I don't know that there's a great way to deal with this and it seems to me like it's adding functionality to support an unofficially supported browser that's breaking good browsers which may end up digging a maintenance hole. But that's all my opinion. Regardless, there's a workaround to this issue that also solves other issues.

Removing the event listener for selectstart makes contentEditable work in Chrome, but still it's not working in Safari.

Fixed by https://github.com/gaearon/react-dnd/commit/0a36033693868a7985ea2348105da4fb2cef8a00.

Removing the event listener for selectstart makes contentEditable work in Chrome, but still it's not working in Safari.

This is HTML5 drag and drop API issue in Safari. Nothing we can do about it.

The fix for this issue was released in [email protected].
Please verify that it works.

Confirmed that Ctrl/Cmd-A works in <input> inside a draggable component.

Attempt to select input or textarea content with touchpad/mouse starts dragging parent element

I see this is not fixed, create a new issue?

Elements with contentEditable set inside a draggable parent container wouldn't allow me to select text or interact with them in any way. After some digging, I found this bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=170139

It appears Chrome has since fixed the issue. Safari's behavior can be fixed in the meantime with CSS:

.contenteditable-element {
  user-select: text;
}

@trevorsmith This is still not fixing the Firefox's behaviour. Do you know any workaround for Firefox?

@rahul1995 - I just found out a solution: just store a ref to the draggable DOM node and when user focuses input/textarea set draggable attribute to false:

const Test = () => {
  const ref = useRef(null);
  const [focused, setFocused] = useState(false);
  const [_, drag] = useDrag({ item: { type: 'test' } });

  useEffect(() => {
    if (ref.current) {
      ref.current.setAttribute('draggable', !focused);
    }
  }, [focused]);

  return drag(
    <textarea ref={ref} onFocus={() => setFocused(true)} onBlur={() => setFocused(false)}></textarea>
  );
};

This should do the trick for Firefox :wink:

Was this page helpful?
0 / 5 - 0 ratings