Drag and Drop issue with scroll

[Márcio Goldschmidt]

Hello everyone.

I have a graph with a simple drag and drop(based on this example: https://jgraph.github.io/mxgraph/javascript/examples/dragsource.html) which works fine. But when I scroll the page down, the DnD function misaligns the cursor over the drop zone. It highlights the wrong item and also gives wrong coordinates on drop event. I'm attaching a gif of the problem since I can't find a cdn of this lib to create a live demo(if someone knows where I find a cdn please tell me and I create a live demo).

I have no clue of what is going on. The code is pretty same of the demo I've linked above. There is no calculations over the coordinates or anything. 

Thanks in advance.

[Gaudenz Alder]

Showing the source code might improve your chance to get an answer.

[Márcio Goldschmidt]

Well, I have found the issue. My graph is rendered inside a tab widget(Kendo's TabStrip) which creates the scroll I have mentioned. Not sure if that could be the problem though, but I have ovewritten mxDragSource.prototype.getDropTarget to this:

       

mxDragSource.prototype.getDropTarget = function(graph, x, y, evt)
{
     var scrollTop = document.getElementById("WorkflowEditTabStrip-1").scrollTop;

     y-= scrollTop;

     return old_DragSource_getDropTarget.call(this, graph, x, y, evt);
};

And it worked. Now I'm trying to figure out how to fix the same issue for internal itens in mxGraph.prototype.getDropTarget method. 

Thanks in adv.

[Márcio Goldschmidt]

Made it work with:

mxGraph.prototype.getDropTarget = function(cells, evt, cell, clone)
{
    var scrollTop = document.getElementById("WorkflowEditTabStrip-1").scrollTop,
        result = null,
        oldPanDy = this.panDy;
   
    this.panDy = scrollTop;

    var result = old_mxGraph_getDropTarget.call(this, cells, evt, cell, clone);


    this.panDy = oldPanDy;

    return result;
};

Now DnD works fine in a graph dislayed within a scrollable container.

[Gaudenz Alder]

Replacing the origin in mxDragSource.dragOver with the following seems to fix it:

var origin = new mxPoint(graph.container.scrollLeft, graph.container.scrollTop);

var origin2 = mxUtils.getDocumentScrollOrigin(document);

origin.x += origin2.x;

origin.y += origin2.y;

This will be fixed in the next release.

[Márcio Goldschmidt]

You mean that it can fix both methods I have overwrite ? I also have to overwrite another method:

mxDragSource.prototype.drop = function(graph, evt, dropTarget, x, y)

{
    var scrollTop = document.getElementById("WorkflowEditTabStrip-1").scrollTop;

    y-= dropTarget.getGeometry().y + scrollTop;

    this.dropHandler(graph, evt, dropTarget, x, y);

    if (graph.container.style.visibility != 'hidden')
    {
        graph.container.focus();
    }
};

This was an already known issue ? Thanks for the support!!

[Gaudenz Alder]

This wasn't a known issue, so thanks for the report. It did work for me with just this fix. Can you check if the other function still needs to be overridden as well?

[Márcio Goldschmidt]

It only fixes the DnD position for already added cells. Adding cells bound with mxUtils.makeDraggable still doesn't works. Do you need a working demo for that? I can try to reproduce it.

[Gaudenz Alder]

Thanks, we've reproduced it. Working on a fix.

[Márcio Goldschmidt]

Just FYI, I'm tracking a new bug we have found related to that. I'm not sure if you guys realize that too. Check the attached webm. After those DnD fixes I had implemented, it still need some fixes for other mouse actions as shown in the video. The edge drag and the connector icon are misplaced with the mouse cursor position. Thanks!!

[Gaudenz Alder]

Another possible fix is this override:

mxUtils.getScrollOrigin = function(node, includeAncestors, includeDocument)

{

includeAncestors = (includeAncestors != null) ? includeAncestors : false;

includeDocument = (includeDocument != null) ? includeDocument : true;

var doc = (node != null) ? node.ownerDocument : document;

var b = doc.body;

var d = doc.documentElement;

var result = new mxPoint();

var fixed = false;

while (node != null && node != b && node != d)

{

if (!isNaN(node.scrollLeft) && !isNaN(node.scrollTop))

{

result.x += node.scrollLeft;

result.y += node.scrollTop;

}

var style = mxUtils.getCurrentStyle(node);

if (style != null)

{

fixed = fixed || style.position == 'fixed';

}

node = (includeAncestors) ? node.parentNode : null;

}

if (!fixed && includeDocument)

{

var origin = mxUtils.getDocumentScrollOrigin(doc);

result.x += origin.x;

result.y += origin.y;

}

return result;

};

[Gaudenz Alder]

This latest fix (for mxUtils. getScrollOrigin) seems to fix all cases for us. Can you check if this works for you, please?

[Márcio Goldschmidt]

It fixes some highlight glitches when dragging over lanes, and cursor misalignment, but it still keeps droping the cell in wrong place. Currently, I have overridden the following methods: mxConnectionHandler.prototype.mouseMove; updatePreviewState and updatePreviewState from mxEdgeHandler.prototype; getDropTarget and drop from mxDragSource.prototype; mxGraph.prototype.getDropTarget, in order to get everything working. Thank you.

[Márcio Goldschmidt]

I mixed the solution you proposed with a fix I developed and it seems to work. My fix is this:

       

mxDragSource.prototype.drop = function(graph, evt, dropTarget, x, y)
{

    // My fix
    y-= dropTarget.getGeometry().y;

    // Original code

    this.dropHandler(graph, evt, dropTarget, x, y);


    if (graph.container.style.visibility != 'hidden')
    {
        graph.container.focus();
    }
};

[Gaudenz Alder]

Does this mean mxDragSource.prototype.drop is the only override needed when our mxUtils.getScrollOrigin is used, or are the other overrides also needed?

[Márcio Goldschmidt]

That's correct. I'm overriding only mxDragSource.prototype.drop now, besides the fix you have suggested.

[Gaudenz Alder]

We can't reproduce this last bug, when I drop a cell into a container (with the mxUtils.getScrollOrigin fix) it the position is correct. Can you explain/show what bug this fixes?

[Gaudenz Alder]

Thanks for the test case. I think this can be fixed as follows (lines 204 ff):

var newCell = new mxCell(null, new mxGeometry(0, 0, 100, 80), cellStyle);

newCell.setVertex(true);

newCell.setValue("Cell #" + ++cellCount);

graph.importCells([newCell], x, y, targetCell);

[Márcio Goldschmidt]

It broken the widget behaviour to me. As I said, the small demo I have provided is just a simple example of my case. In my real code I have bound a mxEvent.MOVE_CELLS event to the graph and according to the importCells docs, it somehow uses the move mothod behind the scenes. So it calls my event and it throws an excelption for unknown reason(I have not debug it), also it starts to behave wierd, cloning cells as I click the lanes and creating a scroll whenever I move the mouse to the bottom of the graph's container. Probably because that exception, I'm not sure. As I call importCells inside between beginUpdate and endUpdate, it never reaches a 'debugger' after the try/catch block.

Idk if I can reproduce it on that repository I have provided, but I can try if you like. Cheers.

[Gaudenz Alder]

Yeah would be useful, it's difficult and time-consuming to debug without a test case.

[Márcio Goldschmidt]

Well, the problem is that I need to make some changes in my move event, but after that I realize I would need more fixes in my wrapper code as importCells seems to behave pretty different from addCells. So I think I will rather keep the drop fix I have made and keep my code than use importCells and change what I have already done so far. Do you think this is so bad practice ? Thanks.

[Gaudenz Alder]

No, that's fine. We'll add this fix to the next release. Thanks for the report and test cases!

[Márcio Goldschmidt]

Thank you for the support!!!