Problems with dnd from a source in one ContentPane to a target in another ContentPane.

[guest]

I've tried a number of different versions of this but any time my source and target are in different ContentPanes? dnd stops working. I first encountered this using Dojo 1.0.x off the CDN. I've also tried it with a downloaded copy and most recently a copy checked out from trunk this morning. My browser is 2.0.0.13 on Ubuntu.

I have two examples. My current example is attached but I have another example posted in the forms linked below.

http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-support/drag-n-drop-source-contentpane-target-outside-pane

You can contact me at grossk at charter dot com if I can be of any further assistance.

[guest]

small HTML page example of the problem

[elazutkin]

It seems like a content pane-related problem. By any chance does the content pane uses iframes?

[bill]

ContentPane doesn't use iframes.

This is a FF2 only (browser bug) when overflow: auto is specified on the source div, like ContentPane does. (I reproduced on FF2 windows.) You can only drop if you move your mouse out of the browser window itself. See also #5285 for the mention of overflow: auto... so you could consider this a DnD bug or a ContentPane bug depending on your point of view.

I'm attaching a simpler test case that doesn't use ContentPane, but also I'll see if I can update dijit.css so this problem doesn't occur.

[bill]

test case not using ContentPane?, showing problem w/overflow: auto on FF2

[elazutkin]

No, this bug is related to #4854, which I closed as "wontfix" after investing a considerable time in it. :-( It is a FF2 bug, and there is no workaround. It is triggered by "overflow: auto" in some configurations, and it looks like the content pane provides such configuration.

I don't know if it is possible to change the content pane code to avoid using "overflow: auto". If it is not possible, I suggest to close the bug with "wontfix" --- nothing we can do about it.

[bill]

OK, closing as wontfix (although basically this is a dup of #4854, or at least a manifestation of it).

The code at issue is in dijit.css:

.dijitContentPane {
	display: block;
	overflow: auto;	/* if we don't have this (or overflow:hidden), then Widget.resizeTo() doesn't make sense for ContentPane */
}

Removing the overflow:auto would solve the problem, but it's bad because it's (arguably) a backwards-compatibility break, and also because it will break things like BorderContainer (the center pane won't have a scrollbar even when it needs one). Although that could be fixed with a .dijitBorderContainer * { overflow: auto; } type rule...

In some cases the user may be able to stick style="overflow: visible;" or style="overflow: hidden" on to their ContentPane to avoid this problem. Of course, that won't work if the user wants a scroll bar.

[bill]

(In [14479]) Add workaround to long-standing FF2 drag problem. Thanks to jfcunat for the fix! Fixes #6345 !strict. Refs #4854, #6350. Also fixing duplicate id's in the test file (if you tried to drag "lettuce" it would think you were dragging "carrot").