[Emscripten] App receives both mouse and touch events on mobile devices
It seems that when running an Emscripten app on a mobile device (tested with Android Chrome, iPadOS Safari), SDL will send both mouse and touch events for the same click/tap.
Using the SDL3 APIs, both a mouse device and a touch device are found present.
Current assumption is that SDL forwards both click and touch start events from the browser. This seems counterintuitive from the perspective of the app, and causes issues if you want to process touch and click events separately.
Note: this is unrelated to synthetic events, which I've disabled using the hints.
I've worked around this issue in my app like this: https://github.com/foxtacles/isle-portable/commit/07e20c329e56e4e91df7189d887b866b861c093a but maybe this can be addressed better by SDL?
Using most recent versions of SDL3 and Emscripten
Hello!
This is normal and documented behavior:
The touch system, by default, will also send virtual mouse events; this can be useful for making a some desktop apps work on a phone without significant changes. For apps that care about mouse and touch input separately, they should ignore mouse events that have a which field of [SDL_TOUCH_MOUSEID](https://wiki.libsdl.org/SDL3/SDL_TOUCH_MOUSEID).
From:
https://wiki.libsdl.org/SDL3/CategoryTouch
So, yes, there is a good and solid way to handle mouse and touch events separately.
@SimonMaracine what you are quoting is about virtual (synthetic) mouse events. I've stated in my issue description that I've explicitly disabled these. This is about real mouse events that I'm getting.
There is absolutely no way to distinguish these mouse events from touch events.
Hmm...we shouldn't be passing both on...preventing default handling should prevent the browser from generating a mouse event to match the touch event:
https://github.com/libsdl-org/SDL/blob/9ed83e71f6cc445316e1b599aad98fa79019544d/src/video/emscripten/SDL_emscriptenevents.c#L523-L526
But I notice we're not preventing default for touch-move events...I wonder if the browser is trying to catch up in that case and generating a mouse button down event since it hadn't yet.
I'll have to look at this closer.
My current thinking on this is that the event handlers are marked passive and emscripten_set_touchstart_callback and friends don't have an interface to specify this.
Passive event handlers aren't allowed to prevent default.
Relevant issue: https://github.com/emscripten-core/emscripten/issues/10091
I suspect the correct thing to do here is stop listening for mouse and touch events and just use the newer (but at this point, widely-supported) Pointer Events, which we already use for pen input. I'm going to take a run at this, but I think we're slipping from 3.2.18 on this one.
Okay, I have a PR that fixes this, but it's way too large of a change for 3.2.18. This can land for 3.4.0, I think.