Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

IE DOM's dragstart Event interferes with 'manual' Mouse Movements


:P
On this page:

I'm working on some JavaScript code for my library that does drag and drop. It's working pretty well and I'd been testing most of my code against dragging around Div tags with drag handles and content which works great. However, depending on how even bubbling is set up in certain browsers the operation hankers quite a bit on individual objects like images or a button, because apparently the browser internal Drag and Drop events interfere.

So the code basically hooks up mouseDown, sets a flag that a drag operation is active and then on mouseMove keeps track of the location and moves the object being dragged to this location. Easy enough.

Except when you do this with say an image in IE you get to initiate the drag operation and move the image 2 or three pixels and then be greeted by the annoying crossed out circle icon which indicates not a drop target. The drag operation won't work properly and the flow is broken. You can see it here:

In the screen shot the image is dragged and you can see the 'Denied!' cursor popping up at the current mouse position while in the middle of the drag operation. Bummer.

The key to get around this is to hook top level document events for this. Specifically I hook the body's dragStart event and assign it a null function ( function NullFunction() { return false; } )  which keeps the event from doing anything. In my code I basically do the following in the JavaScript initialization code:

wwEvent.addEventListener(document.body, "selectstart", NullFunction, true);
wwEvent.addEventListener(document.body, "dragstart", NullFunction, true);  

where addEventListener is a browser independent way to hook up the events. Although neither dragstart or selectstart exist on other browsers they are ignored if they don't exist. This solves the problem.

Incidentally the selectstart event is another  IE issue where if you start dragging an object often times IE sees this as a select all operation selecting all text in say a div that contains text content.

I'll post a sample and code along with an update to wwHoverPanel later this week sometime once I get a few more small issues worked out. I'm still playing around with better ways to detect what is being dropped on. Right now the handler registers drag source and drop sources and then compares locations in the document to determine whether there's overlap and that determines the drop location. It works fine with a single item dropped on a single control, but if there are multiple overlayed controls at the drop position it gets more tricky - especially if no zIndex is set for the controls. Eh, more fun...

There are a number of small tweaks and fixes, especially in relation to the drag panel and drag behaviors in this update as well that got fixed as part of the drag and drop addition.


The Voices of Reason


 

isaac
July 25, 2008

# re: IE DOM's dragstart Event interferes with 'manual' Mouse Movements

hmm working on the same issue with mozilla, perhaps theres a simple solution...

isaac
July 25, 2008

# re: IE DOM's dragstart Event interferes with 'manual' Mouse Movements

hmm just solved it
calling preventDefault() on the event in the mousedown events does it
in case anyone is wondering

E.L.
December 18, 2008

# re: IE DOM's dragstart Event interferes with 'manual' Mouse Movements

"preventDefault()" is for FireFox.
Add the line :
window.event.returnValue = false;

when using IE

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024