mousemove event dispatches when moving anywhere

[sktt]

Greetings, thanks for a great tool...

I discovered that the mousemove event is fired even though the mouse movement happens outside of the targeted DisplayObject.. This may also be true for the touchmove event.

I assume it's only about checking if a hit occured and don't fire unless so..

Is this correctly assumed? Should I open a pr?

[kaariparamesh]

Some kinds of drap/drog wouldn't work if mousemove wasn't called while the cursor is outside the object though, for eg, imagine manipulating a control knob. Once the knob was clicked, it shouldn't let go until mouseup.

[sktt]

Valid point! But I'm not really sure if this use case justifies emitting
mousemove events on to all interactive displayobjects all the time...?

For your example it would actually be wiser to use the pointer lock api
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API to fix
the position while mouse button is pressed. If you for instance look at how
ableton live handles their knobs, they actually do this.

Otherwise ux would be flawed anyway because if your window is small you'd
have to release and move the cursor back every time the it leaves the
window. on top of that the mouseup event will probably not even be captured
cause the cursor is not even inside the browser window anymore..
On Jan 26, 2016 05:28, "alclub" notifications@github.com wrote:

Some kinds of drap/drog wouldn't work if mousemove wasn't called while the
cursor is outside the object though, for eg, imagine manipulating a control
knob. Once the knob was clicked, it shouldn't let go until mouseup.

—
Reply to this email directly or view it on GitHub
#2310 (comment).

[NikkiKoole]

"on top of that the mouseup event will probably not even be captured
cause the cursor is not even inside the browser window anymore.."

thats why there's a mouseupoutside,

here's a similar issue #1250

[sktt]

Since there's already similar issue I guess that has to mean that other developers are also surprised by the behaviour... It's however true that it can easily be checked for so its not really a big deal. I just don't think it makes sense. I could just as well put the mousemove listener to the root container itself

[NikkiKoole]

No it's intended behaviour ;) it does make sense too imo, imagine you putting a mousemove handler on the root, it could work sure, but then you'd need to keep track of the currently dragging item in the root (to be set in the mousedown handler of the item), now imagine using touch and doing that for 10+ items ;)

Just set some property 'isDown' or something when you start a mousedown on an item, then in your mousemove do the moving and set the isDown = false in the mouseup(outside) of that item

[GoodBoyDigital]

Hello! We have decided to offer the best of both worlds for this issue.
there is a new property in the interactionManager called moveWhenInside
Setting to true will make things work more in line with how the DOM verison works.
Setting to false will mean the mousemove and touchmove will be dispatched regardless of weather the cursor is over the object.

The default of this property is true. 👍

[sktt]

Thanks @GoodBoyDigital !
A small typo though.. #2347

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.