The reason why this, most probably, happens is that the mouse doesn't travel along a continuous path, it jumps. When you move it slowly you jump a pixel or two each time, so you don't notice it. When you flail it around wildly you can jump over 100 pixels between polls.
Since your mouse is now over something else it's normal for the event for that to trigger first and then, when the browser loop catches up, the out event is detected as well. One can say that the "importance" of the over event is higher since it's a callback (mouse moved) and not a poll (what else do I have lying around?).
If you want something to happen and depend on the order of these events I suggest you check in your over
handler that any out
actions are taken before handling the over
event. Basically you do this:
- On first over event (the variable is null) save what is the current element.
- On the next over event where the variable is not the current element handle the out event for the old element and set the variable to the currently hovered element.
- On an out event handle the out and set the element to null.
This will give you a forced order of events even if the actual over
happens before the preceding out.
You can also use the out
event only to track is the mouse is out of all the drop zones and do some reset there. And use the over
event to handle all the in drop zone dragging...