Problems with inputs and textareas inside of draggable component

[playpauseandstop]

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,

[dperetti]

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 :
dperetti@06f74ef

[gaearon]

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).

[ostinru]

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

[gaearon]

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 #178 (comment).

[stevenhauser]

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.

[gaearon]

The original issue was #128.
If you can prepare a PR that fixes the problem, but also keeps #128 working, that would be a huge help.

[stevenhauser]

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

[gaearon]

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

[stevenhauser]

@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.

[danielbuechele]

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

[gaearon]

Fixed by 0a36033.

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.

[gaearon]

The fix for this issue was released in react-dnd@1.1.8.
Please verify that it works.

[playpauseandstop]

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

[sstefoss]

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

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

[trevorsmith]

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;
}

[rahul1995]

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

[megawebmaster]

@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 😉

[scottydev]

@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 😉

Have you considered making a PR? This is a fairly big issue on Strapi when entering data and happens on Chrome too.

strapi/strapi#12432

[megawebmaster]

To be honest I didn't, because I didn't know where to start - if anyone can point me in the right direction I'm happy to work on the issue 👍

[scottydev]

All good, digging in more I saw that your fix has to be applied outside the scope of the react-dnd core. Was trying to apply it to this ref, but the Strapi contrib process was not working correctly on my M1 machine 😅

There may be a way to use the logic you propose on nested elements and have it bubble up to the draggable ref so we fix it at the React-dnd level for all to make benefit, but we'd have to dig in more to see how that would work.

[sean-mcclure]

This is a vanilla JS issue, not a React issue. Programmatically focusing the input element when its clicked on fixes the issue.

[megawebmaster]

@sean-mcclure - so you think a solution like this should work?

const Test = () => {
  const [_, drag] = useDrag({ item: { type: 'test' } });

  return drag(
    <textarea onClick={(e) => e.target.focus()}></textarea>
  );
};

Why is this a vanilla JS issue and is it reported anywhere in Gecko (Firefox) or Blink (Chromium based browsers)?

[trainoasis]

A year later almost, but I for some reason found a now soon-to-be-deprecated repo react-sortable-hoc way more intuitive to work with. Have more troubles setting the new repo up for some reason 🤔 Am I the only one ? Are we exchanging flexibility for the ease of use?

[rbehal]

This is not documented very well, but if you add the class name nodrag this works to not allow dragging by the text input field, meaning you can select and highlight text with your cursor.

No other solutions solved my issue.

      <>
        <Input
          disabled={isDisabled}
          value={value}
          onChange={handleChange}
          className={'nodrag'}
          placeholder={placeholder}
          multiline
          error={error_message}
        />
      </>