Ticket #4854 (closed defect: wontfix)

Opened 13 months ago

Last modified 4 months ago

drop failure

Reported by: guest Owned by: elazutkin
Priority: high Milestone: 1.1
Component: DnD Version: 0.9
Severity: major Keywords:
Cc:

Description (last modified by bill) (diff)

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

dndTestCase.html (5.4 kB) - added by guest 13 months 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.

Change History

Changed 13 months ago by guest

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.

Changed 13 months ago by guest

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

Changed 13 months ago by elazutkin

  • status changed from new to assigned
  • milestone set to 1.0

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

Changed 13 months ago by elazutkin

  • milestone changed from 1.0 to 1.0.1

Changed 12 months ago by peller

  • milestone changed from 1.0.1 to 1.0.2

Changed 12 months ago by peller

  • milestone changed from 1.0.2 to 1.0.3

Changed 9 months ago by dylan

  • milestone changed from 1.0.3 to 1.2

Changed 9 months ago by elazutkin

  • priority changed from normal to high
  • severity changed from normal to major
  • milestone changed from 1.2 to 1.1

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

Changed 9 months ago by elazutkin

  • status changed from assigned to closed
  • resolution set to wontfix

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.

Changed 8 months ago by bill

  • description modified (diff)

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

Changed 4 months 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.