#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 )
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)
Change History (11)
Changed 13 years ago by
Attachment: | dndTestCase.html added |
---|
comment:1 Changed 13 years ago by
I forgot to tell that I work in strict DTD. I don't know if it affects anything but...
comment:2 Changed 13 years ago by
Milestone: | → 1.0 |
---|---|
Status: | new → assigned |
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 13 years ago by
Milestone: | 1.0 → 1.0.1 |
---|
comment:4 Changed 13 years ago by
Milestone: | 1.0.1 → 1.0.2 |
---|
comment:5 Changed 13 years ago by
Milestone: | 1.0.2 → 1.0.3 |
---|
comment:6 Changed 13 years ago by
Milestone: | 1.0.3 → 1.2 |
---|
comment:7 Changed 13 years ago by
Milestone: | 1.2 → 1.1 |
---|---|
Priority: | normal → high |
severity: | normal → major |
After reviewing the effects I found this bug to be fairly major => scheduling it for 1.1 release.
comment:8 Changed 13 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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 13 years ago by
Description: | modified (diff) |
---|
See also #6350, a manifestation of this bug for ContentPane.
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.