Feature request: option to not block non-ReactDnD drag operations

[Macil]

Right now all drag-and-drop operations that aren't managed by React-DnD are blocked. On pages that already have non-React-DnD drag-and-drop-handling code, this causes things to break while React-DnD is active. An option to disable this behavior would be useful.

For the current time, I've put up a version of react-dnd-html5-backend that's patched to have this disabled on npm.

[fixpunkt]

I'm currently facing a similiar problem, so thanks @agentme for providing a fork with npm packages! However, it doesn't quite fix my problem and I'm trying to figure out what's going wrong.

In HTML5Backend.prototype.handleTopDropCapture, you have the following code which will prevent the backend from calling event.preventDefault():

if (!this.monitor.isDragging()) {
  // This is probably a native item type we don't understand.
  return;
}

However, in my case this.monitor.isDragging() always returns true, because react-dnd will just treat my non-react draggable element as a native draggable. How can I actually prevent this from happening? Is there something I'm missing here?

[Macil]

because react-dnd will just treat my non-react draggable element as a native draggable

Are those terms not synonymous here?

[fixpunkt]

Actually, yes, I was not making the distincion clear enough. I have non-react draggables that should not be processed by react-dnd, which is what I understand your fork is designed for. However, react-dnd will recognize my draggables as native draggables and then try to process them anyway (because, apparently, you can drag non-react stuff into react-dnd containers), which will cause monitor.isDragging() to return true, which will cause the above check to fail, which will in turn call event.preventDefault() on the drop event for those draggables, which prevents CKEditor from processing them correctly.

To restate my question: If I want to keep react-dnd from not blocking other dnd operations, is there anything else I have to do besides switching to your fork? Like, calling event.stopPropagation() on the dragstart event of the draggables?

[Macil]

Oh, the issue is that I only needed and tested that this allows files to be dragged into the browser onto non-React-DnD dropzones. I didn't test draggable non-React-DnD elements. More changes will be needed to support that which I haven't looked into.

[fixpunkt]

Ok, good to know. I think I'll have a go tomorrow.

[fixpunkt]

So, I tried if I can keep monitor.isDragging() from returning true by stopping drag events from bubbling from the CKEditor, but this didn't work.

I ended up using the vanilla HTML5 backend, preventing all drag events from bubbling and monkeypatching HTML5Backend.handleTopDropCapture() to only run when the dragged element is not one of my native draggables inside the CKEditor.

It would be really nice to have a better way of doing this, but I can't figure anything out right now since I don't really understand the internal architecture of the backend. I think one possibility might be to just never call event.preventDefault() when the drag event doesn't get handled by react-dnd, but I'm not certain which consequences this entails.

[nickbouton]

+1 for @agentme's original sentiment here. We're using AlloyEditor (a React component based on CKEditor as well) in conjunction with React-DnD in a project side-by-side and I noticed that React-DnD was somewhat greedily clobbering our ability to drag-and-drop images into the editor.

@agentme's fork fixed this for me (thanks!), but it would be great if this were an option of some sort in the official supported project as well.

[nickpresta]

@gaearon Is there anything I can do to help get the @agentme fork merged in? The changes look relatively straightforward, and I'm currently experiencing the pain with another file upload (via HTML5 dnd).

Is there something I'm missing or is this backend supposed to be all powerful and prevent bubbling?

Thanks!

EDIT

After taking a closer look, I understand that you may want to use DnD to handle native items, such as file upload, which is why the original code exists. It seems unlikely that the inclusion of a feature that ignores some items would be included (perhaps an option, though).

I decided to take a look at what @agentme did in his fork and built a "local" non-native backend in our application.

Here is what I ended up doing: https://gist.github.com/nickpresta/eb5cce69d650db4c2795

[Macil]

I think merging my fork would make sense if the issue @fixpunkt brought up was fixed: my fork leaves non-DnD draggable items broken.

[brianium]

@agentme thanks for this! Super helpful

[ncphillips]

What is the status of this issue?

Should I switch to the fork provided by @agentme? or the gist that @nickpresta shared?

[0rvar]

This behaviour causes our CodeMirror instance to ignore drag and drop, it does nothing when e.defaultPrevented === true. Is a fork the way to go? Is this a perma-issue?

[0rvar]

We managed to solve our problem this way:

import HTML5Backend from 'react-dnd-html5-backend';
import { DragDropContext } from 'react-dnd';

const ModifiedBackend = (...args) => {
	const instance = new HTML5Backend(...args);
	
	const listeners = [
		'handleTopDragStart',
		'handleTopDragStartCapture',
		'handleTopDragEndCapture',
		'handleTopDragEnter',
		'handleTopDragEnterCapture',
		'handleTopDragLeaveCapture',
		'handleTopDragOver',
		'handleTopDragOverCapture',
		'handleTopDrop',
		'handleTopDropCapture'
	];
	listeners.forEach(name => {
		const original = instance[name];
		instance[name] = (e, ...extraArgs) => {
			if (!shouldIgnoreTarget(e.target)) {
				original(e, ...extraArgs);
			}
		};
	});

	return instance;
};

// Decorate root elements with this
export default DragDropContext(ModifiedBackend);

This does however feel like a hack, and we'd prefer an official solution