Tree: scrolling triggers a drag

[isza]

I have a DnD-enabled Tree in a ContentPane? with a scroll bar. In Firefox 3.5 and Internet Explorer 8, after selecting an item, when dragging the scroll bar, the drag operation of the selected item is started. In webkit based browsers everything seems to work.

I have changed dijit.tree.dndSource to dijit._tree.dndSource, and tried the same code with dojo 1.3.2, and the bug disappeared in all the browsers.

[isza]

Replying to peller:

This is a regression, because it works in 1.3.2, and it doesn't work in 1.4.0.

[isza]

Replying to peller: ​1.3.2 test, ​1.4.0 test

[bill]

I tried it, it works fine for me. If you can attach a test case that reproduces then feel free to reopen this ticket.

I'll attach my test case.

[bill]

tree in contentpane w/dnd

[CnEY]

Bill, the bug is not reproducible in your test case because in that case, the scrollbar isn't on the top level node of the tree, but above that, on the content pane. Perhaps that's a legitimate workaround (or even qualifies this as "not a bug"?).

I can give you a way to reproduce this within dijit/tests/tree/test_Tree_DnD.html, in both the tree and non-tree DnD containers. (The following reproduction steps are basically a recap of the conversation that happened between isza, myself, and dmachi in the dojo channel on Jan 4.)

1. Load ​http://download.dojotoolkit.org/release-1.4.0/dojo-release-1.4.0/dijit/tests/tree/test_Tree_DnD.html

2. Use Firebug to edit the CSS of the .container class (easy way to find it is activate click-to-inspect, then click one of the gray rounded borders), and add the following styles: height: 50px;

overflow: auto;

3. Click on an item in one of the DnD containers to select it.

4. Click and drag the scrollbar to scroll, and you'll see that it also apparently triggers a DnD start event.

If my memory serves me correctly, however, I noticed during the conversation that this also happens in 1.3.2, which means it's not a regression, and presumably therefore not a candidate for 1.4.1.

[bill]

(As I said above) I need you to actually attach a test case, thanks.

[bill]

I reread CNeY's comment, and actually this can be reproduced on test_Tree_DnD.html without modifying CSS, just do:

1. Load ​http://download.dojotoolkit.org/release-1.4.0/dojo-release-1.4.0/dijit/tests/tree/test_Tree_DnD.html

2. Click on an item in upper right container to select it.

3. Mouse-down and drag the scrollbar to scroll, and it triggers a DnD start event (the avatar shows up to the right of the scrollbar)

As CNeY said the workaround is to put the scrollbar on the surrounding node, rather than the DnD container node.

Also, not that this isn't a Tree bug, or at least it's not solely a Tree bug, as it happens with a plain DnD container as shown above. Probably the drag shouldn't start unless the mouse down occurs over a drag item? Mouse down over the container doesn't seem sufficient.

Eugene - assigning to you for the bug in the dojo.DnD code.

[kludgeless]

Ran into this with a tree inside a BorderContainer?. Everything works fine until the tree's container is resized, at which point this bug surfaces. If you'd like the sample used, I can provide it. As suggested, surrounding the tree with an extra div with "overflow: auto" set fixes the problem. A lot of time was spent tracking down the issue and devising a workaround that actually worked in a more complicated setup, so a fix would be appreciated! :-)

[Stefan Bird]

This problem seems to be exacerbated by the fact that Tree sets overflow: auto on its domNode every time it's resized:

​http://bugs.dojotoolkit.org/browser/dijit/trunk/Tree.js?rev=22498#L1583

[bill]

See also #11491, which suggests setting Tree to overflow: hidden.

[Jonathan Bond-Caron]

Sample patch, FF 3.6

[Jonathan Bond-Caron]

I've attached sample patch for this, the root of the problem seems to be that dojo should have cross-browser way of finding out if a dom node has a scrollbar and getting the positioning of the scrollbar.

[bill]

@jbondc - I guess checking for a scrollbar width is one way to solve the issue. ISTM the other way is, as I said above, don't start a drag unless the mouse down occurs over a drag item. IOW, ignore mouse down over the container.

How would you compare those two approaches? Is there something I'm missing about my suggestion that doesn't work?

[Jonathan Bond-Caron]

It depends on what the expected behavior is...

BEHAVIOR A (currently in dojo) Allow drag to start with a 'mousedown' anywhere in container + 'onmousemove'

In this case, there needs to be some sort scrollbar calculation on some browsers since the standards are lacking in that area.

BEHAVIOR B (what you're suggesting)

Allow drag to start with a 'mousedown' on a node with class 'dojoDndItem' + 'onmousemove'

That would mimic the dnd behavior on windows and I believe most UI's do...

dojo/dnd/Source.js onMouseDown: function(e){ check for 'dojoDndItem' }

IMHO, there are cases when the A is less frustrating for the user then B. But overall, B is a simpler fix and intuitive for users.

I'll attach images for the different behaviors.

[Jonathan Bond-Caron]

Current dnd source behavior

[Jonathan Bond-Caron]

Possible new behavior

[Mewel]

I have the same problem. The workaround with the div works only for the vertical scrollbar.

I don't understand why the priority is set to low. Imho, a dojo tree with dnd is not useable because of this bug.

[eeid]

I am evaluating the dojo 1.6 tree and this bug makes the tree useless if you need dnd in the tree. This bug should not be low priority. it happens in (ff 4.0+5.0 + chrome).

The problem can be duplicated with the following steps: 1) Select an item in the tree. 2) Click on the horizontal scroll bar and drag the mouse towards the tree. 3) The drag and drop should start.

My temp fix in my evaluation code to fix the issue was like this.

dojo.connect(myTree.dndController,"onMouseDown",function(e){

get the tree var tree = dojo.query("#myTree")[0];

if (e.pageX>tree.clientWidth-ScrollBarWidthOrHeight?)

myTree.dndController.mouseDown=false;

this.inherited(arguments);

})

Unfortunately, I tried to fix the dnd with horizontal bar this way, but it did not work.

I found this code to find the scroll bar width\hight. (it's not mine)

function getScrollBarWidthOrHeight () {

var inner = document.createElement('p'); inner.style.width = "100%"; inner.style.height = "200px";

var outer = document.createElement('div'); outer.style.position = "absolute"; outer.style.top = "0px"; outer.style.left = "0px"; outer.style.visibility = "hidden"; outer.style.width = "200px"; outer.style.height = "150px"; outer.style.overflow = "hidden"; outer.appendChild (inner);

document.body.appendChild (outer); var w1 = inner.offsetWidth; outer.style.overflow = 'scroll'; var w2 = inner.offsetWidth; if (w1 == w2) w2 = outer.clientWidth;

document.body.removeChild (outer);

return (w1 - w2);

};

[maheshn]

Hi All,

I have the same problem and even after wrapping the tree with an extra div with "overflow: auto" its not working in IE.

Then I tried with another solution, by capturing the scroll event on wrapper DIV component and suppressing the Dnd event by calling 'onDndCancel'. However its working perfectly fine with both horizontal and vertical scroll bar movements, but its not working in IE (its unable to capture 'onscroll' event for DIV ).

Any help will be appreciated.

Thanks Mahesh

[tsummerall]

Yes, this bug is a big deal because the workarounds are not effective. Please change priority from "low".

[bill]

Essentially dup of #13964, except that this is about the Tree which has it's own version of the DnD code. I'll leave this one open so we don't forget about fixing Tree.

[dylan]

Given that no one has shown interest in creating a patch in the past 5+ years, I'm closing this as patchwelcome.