Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#4854 closed defect (wontfix)

drop failure

Reported by: guest Owned by: Eugene Lazutkin
Priority: high Milestone: 1.1
Component: DnD Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

Hi everyone, I noticed a little problem while using DnD. Under particular conditions, drop is failing on firefox (2.0) I'll add a testcase to this ticket but here the thing:

I have two divs, each containing a dndSourced table. No problems for now but if I add an overflow:auto on containing divs, dropping's behavior become a bit random. It seems that the 'onover' event is not fired every time for the drop target. That behavior concerns only firefox as I can tell. Seems ok for ie7, netscape, opéra and safari (windows XP)

Attachments (1)

dndTestCase.html (5.4 KB) - added by guest 12 years ago.
here's the testcase. In the css class 'containerDiv', if you remove the overflow:auto, it works. It works too if you remove the 'width:100%' in 'containerDiv table', really don't know why.

Download all attachments as: .zip

Change History (11)

Changed 12 years ago by guest

Attachment: dndTestCase.html added

here's the testcase. In the css class 'containerDiv', if you remove the overflow:auto, it works. It works too if you remove the 'width:100%' in 'containerDiv table', really don't know why.

comment:1 Changed 12 years ago by guest

I forgot to tell that I work in strict DTD. I don't know if it affects anything but...

comment:2 Changed 12 years ago by Eugene Lazutkin

Milestone: 1.0
Status: newassigned

Looks like a Firefox-specific bug, but I'll look to make sure we cannot do anything on our side to fix it.

comment:3 Changed 12 years ago by Eugene Lazutkin

Milestone: 1.01.0.1

comment:4 Changed 12 years ago by Adam Peller

Milestone: 1.0.11.0.2

comment:5 Changed 11 years ago by Adam Peller

Milestone: 1.0.21.0.3

comment:6 Changed 11 years ago by dylan

Milestone: 1.0.31.2

comment:7 Changed 11 years ago by Eugene Lazutkin

Milestone: 1.21.1
Priority: normalhigh
severity: normalmajor

After reviewing the effects I found this bug to be fairly major => scheduling it for 1.1 release.

comment:8 Changed 11 years ago by Eugene Lazutkin

Resolution: wontfix
Status: assignedclosed

After spending the whole day chasing this problem (it came up in a project I am working on at the moment) I am convinced that this is a Firefox bug and there is no sane workaround for it on our side.

I tested Firefox 1.5 and 2, and both are affected. In certain situations after pressing a mouse button and dragging Firefox reports realistic coordinates, but its target node is stuck on some element regardless of the actual position of the mouse. The bug is triggered by "overflow: auto" settings in CSS but it is not enough. I suspect that tables should be present as well because the flickr_viewer demo works without problems using "overflow: auto".

I couldn't reproduce this bug in Firefox 3. It looks like they fixed it. This bug should be filed with Mozilla, but I doubt they would actually fix it in 1.5-2, when Firefox 3 is coming real soon. I mark it as "wontfix" because we (Dojo) cannot fix it.

comment:9 Changed 11 years ago by bill

Description: modified (diff)

See also #6350, a manifestation of this bug for ContentPane.

comment:10 Changed 11 years ago by 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").

Note: See TracTickets for help on using tickets.