Reconcile handling of mouse and touch drag start events #545
Conversation
…events Attach the mousedown event handler to the node, likewise to the touchstart, so that it may be cancelled if needed, avoiding a click after drag.
|
Hmm, this is interesting. Can you point me to a use case / example code where this change makes a difference for you? |
|
I'm not sure I can. Having different code paths for mouse and touch events just looks inelegant (e.g. one receives a browser event and another a synthetic event). I made this change as part of handling click-vs-drag issues like #531, #419 and #409 . It seems like I've made things to work even without this change though, so I can't say it's absolutely necessary, it just looks like it would make things a bit cleaner. This is a merge offer, not a pull request;) |
|
The comment would need to be reworded though; this doesn't by itself make it possible to cancel the click event after drag. |
|
That makes sense. I'll test it and see if this changes anything upstream. |
Attach the mousedown event handler to the node, likewise to the touchstart, so that it may be cancelled if needed and otherwise handled more uniformly