After applying this fix for IE (which seems to be absolutely necessary for draggables when ghosting=true): http://dev.rubyonrails.org/attachment/ticket/10207... In ie7 and lower, when the containing div (with overflow:auto;) for draggables is scrolled, the draggable elements appear stuck -- as if their position is fixed to the containing div. Here is the HTML to reproduce the bug in IE: http://pastie.org/213948 I am using Scriptaculous 1.8.1 and Prototype 1.6.0.1 I have also posted this as a bug here: http://prototype.lighthouseapp.com/projects/8887/t... Many thanks, and any help is much appreciated Phillip
on 2008-06-12 21:59
on 2008-06-12 23:08
Try using DragDropExtra from http://scripteka.com/. I'm using it with some level of success. I'm interested to know if you run into the same problems with it that I am experiencing. This whold drag & drop from within an element with any sort of overflow seems to be the bane of this library. Nevertheless I still like it. It's kinda like a hot chick with stinky farts. Can you get past that?
on 2008-06-13 19:27
I applied the patch you mentioned: http://scripteka.com/script/dragdropextra Thanks, it seems to be a good fix although it is/becomes buggy... for instance, it will change the dimensions of the draggable, or only drag the text, or (in ie6 & ie7) the draggable will be offset from where it is initially selected when dragging it a second time. To fix the dimension changing issue, I declared in the CSS that the height and width were !important. You can see these issues and functionality in this test case: http://pastie.org/214559 Try removing the !important declarations in .draggable to see the dimension changing issues. To fix the issue of the draggable being offset from the cursor on the second drag in IE, I have no idea. But i think it's is a minor issue in comparison to the original bug. Any thoughts?
on 2008-06-13 22:03
Yeah, I got that second drag bug too. I have notified the developer about that, and he will be working on it within the next week or so is my guess.