playcanvas / engine

JavaScript game engine built on WebGL, WebGPU, WebXR and glTF
https://playcanvas.com
MIT License
9.7k stars 1.36k forks source link

Element still recieves touchend event if useInput=false #3687

Open robplaywind opened 3 years ago

robplaywind commented 3 years ago

Description

The element dragging described here uses the ElementDragHelper object.

If an element starts to be dragged via mouse, and useInput is set to false on the dragging element after this, when it is dropped the element does not receive the "mouseup" event. This is the desired behavior as it allows me to know which element this dragged element was "dropped on" (The element under the cursor when the drag ends). This allows for UI drag and drop functionality.

The issue is that when touch is used (Desktop Google chrome touch emulation), the dragged element receives the touchend event, even if useInput is set to false. This is not desired, as the element under gets no event (because the dragged one got the event), meaning I cannot know what element should receive this drop.

Steps to Reproduce

  1. Setup a new ElementDragHelper on an element.
  2. Use google chrome mobile viewport: https://developer.chrome.com/docs/devtools/device-mode/#viewport (reload Launch tab otherwise touch doesn't work properly).
  3. Using the "drag:start" event from the ElementDragHelper object, set useInput to false on the element.
  4. Observe how when dragging ends via touch, the dragged element still receives "touchEnd", if it was under the touch pointer.
  5. Repeat and observe how the element does not receive "mouseup" if it was under the cursor.

In my implementation, i use requestAnimationFrame() to wait a frame before setting useInput to false, but I do not think this should matter.

yaustar commented 2 years ago

Side note: this was done to make it easier to know what element was it dragged to to create a drag and drop UI

yaustar commented 2 years ago

Looks like it could be related to this as well: https://github.com/playcanvas/engine/issues/2165

AFAIK, there was deliberate decision to have this behaviour because that is what the browser does (ie the mouse and touch events behave differently).