Event Ordering for touch and mouse events

[diyaayay]

Resolves #7260 and #7195

Changes:

• Replaced mouse events with pointer-events to collectively handle mouse and touch inputs.
• Updated mouse tests to use pointer events

Description:
I have tested all the examples given for both the issues above on an Android device, and Windows. The outputs are same for both the touch device, and mouse.
Screenshots of the change:

PR Checklist

• npm run lint passes
• Inline documentation is included / updated
• Unit tests are included / updated

[diyaayay]

@davepagurek @limzykenneth I've tried to maintain the original behavior that these issues aim to address. We also discussed the deprecation of touchStarted() and touchEnded(). Should these still be deprecated, leaving only mousePressed() and mouseReleased()?

[limzykenneth]

If there are no special differences between touchStarted/Ended() and mousePressed/Released(), then let's remove touchStarted/Ended().

[diyaayay]

If there are no special differences between touchStarted/Ended() and mousePressed/Released(), then let's remove touchStarted/Ended().

I've removed them from mouse.js. So, does that mean that the inline documentation would change to something like "mousePressed()/Released()/Moved()` works for both the mouse and touch events, or should it only mention mouse features and no touch features at all?

[limzykenneth]

It probably can mention supporting touch as well although there may not be practical differences.

[diyaayay]

It probably can mention supporting touch as well although there may not be practical differences.

Is there anything else that needs to be done in this PR? #6738 and #6739 are reverted because of changes in this PR but I don't think that breaks anything.

[limzykenneth]

Do these and the touch ones below still need to be here?

[diyaayay]

Oh yes! I missed these during the cleanup. But I think we need the touch ones for the touches[] array since we're handling multiple touches with touch events. I've removed the mouse events.

[limzykenneth]

I wonder if it would be possible to implement touches[] with pointer events as well, essentially caching the events as they come in, perhaps something like described here: https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events/Multi-touch_interaction

[diyaayay]

I did implement touches[] with pointer events and the sketches seem to work just fine but the tests fail currently. I'll try to fix these.

[limzykenneth]

If the local test sketches you tried are working as intended then it should be fine for now, you can try to fix the tests if it is easy to do but that's not a priority as I may need to rewrite them later.

[diyaayay]

I realized later that if I implement touches with pointer-events then onpointerup()/down()/move() exists in both mouse.js and touch.js and mousePressed()/Released() stops working. I think this is because, for sketches, these events fire from both touch.js and mouse.js in parallel. So, maybe the choice lies between having one file pointer.js/ one file which would have pointer events for touches and mouse or letting the touches be decoupled by using touch events.

I did try a pointer.js handling touches and mouse on the basis of event.pointerType and everything seems to work. Let me know if I should go with this approach.

[limzykenneth]

Yes, let's go with just one file pointer.js

[diyaayay]

I've tested the examples and they seem to work fine.

[limzykenneth]

For the test we'll probably transition to use Vitest Browser Mode Interaction API but I can handle that after this is completed.