d3.drag() causes error in testing mousedown event via jsdom about d3-drag HOT 4 CLOSED

I did a little digging here and was able to reproduce the error locally, by running npm test.

I tracked down the error to this part of d3-drag:

function nodrag(view) {
  var root = view.document.documentElement,
      selection = d3Selection.select(view).on("dragstart.drag", noevent, true);
  if ("onselectstart" in root) {
    selection.on("selectstart.drag", noevent, true);
  } else {
    root.__noselect = root.style.MozUserSelect;
    root.style.MozUserSelect = "none";
  }
}

It's the view.document line that is throwing the error. Apparently there is no .document property defined on the view object.

  function mousedowned(event, d) {
    if (touchending || !filter.call(this, event, d)) return;
    var gesture = beforestart(this, container.call(this, event, d), event, d, "mouse");
    if (!gesture) return;
    d3Selection.select(event.view).on("mousemove.drag", mousemoved, true).on("mouseup.drag", mouseupped, true);
    nodrag(event.view);
    nopropagation(event);
    mousemoving = false;
    mousedownx = event.clientX;
    mousedowny = event.clientY;
    gesture("start", event);
  }

The view object is derived from the event object.

Here's the relevant bit of d3-selection code that passes the event object into mousedowned:

function contextListener(listener) {
  return function(event) {
    listener.call(this, event, this.__data__);
  };
}

I think it comes down to the fact that d3-drag was designed to work only in the browser. The browser does provide event.view.document, and this Node-based testing setup does not provide event.view.document apparently.

The question here really is - should d3-drag support non-browser environments?

If so, how much effort is warranted to make this happen?

If anyone with deep knowledge of these testing tools and simulating the DOM API in Node has a proposed solution, it would be great to see a PR contributed for non-browser support.

from d3-drag.

@mbostock why close this issue?
Wouldn't it be better to give an explanation about the question asked?
I have this problem too.

from d3-drag.

Ah - there's usually a template that goes with issue closures of this sort. I'm guessing (but not 100% sure) that the closure is of this spirit. Pasting it here from another closed issue:

It is often impossible to debug from code snippets alone. Isolate the issue and reduce your code as much as possible before asking for help. The less code you post, the easier it is for someone to debug, and the more likely you are to get a helpful response.

If you have further questions, please use Stack Overflow tag d3.js to ask for help. Stack Overflow provides a better collaborative forum: thousands of D3-related questions have been asked there, and some answers may be relevant to you.

If you have a question about D3’s behavior and want to discuss it with other users, also consider the d3-js Google Group or joining the d3-js Slack.

Thank you! 🤗
Originally posted by @mbostock in #51 (comment)

Also, the .zip is included, but there are no instructions for how to reproduce the error. That would also help.

Another aspect is, D3 is designed to support working in the browser. Getting it to work in a React testing context with JSDom is not really a core use case for D3, and my guess is that this is probably a shortcoming of the testing environment, rather than a shortcoming of D3.

from d3-drag.

I found a solution to this specific problem. The fireEvent mouse* methods have options. passing in jsdom's global.window into view should populate D3's view.document.documentElementdown the line:

fireEvent.mouseDown(scrollBarHandle, {
  clientX,
  clientY,
  ...,
  view: global.window,
});

For anyone else grappling with this problem, note that there isn't much SVG support with jsdom and you might find other issues with D3's test setup with jsdom

from d3-drag.