-
Notifications
You must be signed in to change notification settings - Fork 6.8k
fix(drag-n-drop): ignore consecutive touchmove events on drag item on multitouch #15923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… multitouch Bumped into an inconsistent behaviour on multitouch. Currently the DragDropRegistry is designed atop of Set, and assumes there could be only one pointer active on item. Which is not true for multitouch devices. So there’re two ways to fix it: 1. Teach DragDropRegistry to respect multiple simultaneous pointers on one item. 2. Stick to Set as designed initially, respect only the first pointer on item, and properly ignore all consecutive pointers. The first way looks much more promising, but requires much more effort and requires attention of core team, I suppose. The second one is not that flexible, but is still more consistent than the current implementation. So this commit implements the second way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for the most part, but needs a bit of cleanup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bumped into an inconsistent behaviour on multitouch. Currently the DragDropRegistry is designed atop of Set, and assumes there could be only one pointer active on item. Which is not true for multitouch devices.
So there’re two ways to fix it:
The first way looks much more promising, but requires much more effort and requires attention of core team, I suppose. The second one is not that flexible, but is still more consistent than the current implementation. So this commit implements the second way.