The reason this is most likely happening is because the mouse is not moving along a continuous path, it is jumping. When you move it slowly, you jump in pixels or two each time, so you donβt notice it. When you spin it around, you can jump over 100 pixels between polls.
Since your mouse is now above something else, this is normal for an event for which it is fired first, and then when the browser loop ends, the out event is also detected. We can say that the βimportanceβ of the over event is higher because it is a callback (moving the mouse), not a poll (what else do I have?).
If you want something to happen and depend on the order of these events, I suggest you check your over handler that any out actions are performed before the over event is processed. You basically do this:
- In the first event (the variable is null) save what is the current element.
- In the next event, where the variable is not the current element, it processes the out event for the old element and sets the variable to the current hanging element.
- In the output event, handle the output and set the element to null.
This will give you a forced order of events, even if the actual over happens before the previous one.
You can also use the out event only for tracking, since the mouse is outside all the reset zones and does a few reset there. And use the over event to handle all draggable drag zones ...
source share