Closed dr0ps closed 4 years ago
Hi @dr0ps, thank you for the PR. It usually should avoid doing the default action for dragging. Especially, touch devices need that because touch events have default actions. Then, this PR breaks many apps and makes many tests fail. Therefore, unfortunately this PR can't be merged. And use your customized library for your app.
Yeah, sorry. I noticed the problem with the scrolling already. Seemed too good to be true.
:smile:
For documentation purposes: It works well for me with preventDefault: true and stopPropagation: false. Then I can not use a click-handler since the click is not generated by the default handler. But I can use touchstart/touchend to check for a click myself.
In typical UI design, an element (e.g. container element) can be dragged, and another element (e.g. nested element) accept clicking. That is, there are separate elements for user operations (not events). This can avoid confusing users. For example, when user released the mouse button (or touching) before moving element, the operation is misunderstood as a clicking.
I need to use a click handler on the draggable objects. This works well with the mouse but does not work with touch devices since plain-draggable stops the event propagation for touchstart/touchend. This commit sets the options for the used PointerEvents instance to not stop event propagation and not prevent the default handling. This solves my problem and does not seem to cause other problems.