@brendanduncan_u3d When you need to use a web standard, more often than not a user interaction is necessary, in the form of a click. The way I do this, is by using a pointerdown event on Unity, so that on the jslib I call a pointerup, this way the user interaction is registered. However, I’ve been getting reports that this is not working properly with the new input system, that sometimes users need to tap twice for the click to register.
Am I missing something that I need to do to make this work with the new input system as well? Thanks!
I’m guessing it’s because the events are queued and not directly tied to the pointer down event in the browser. In the jslib, you could register a pointerdown/up event on the canvas on page load to make sure you’re in the browser user event handler.
It’s a function that binds a pointerup on the document. The user in Unity is supposed to call the method on a pointerdown. This works perfectly fine for the old input system. On the new one, I get reports that it fails (more accurately, that the user needs to tap twice, which means the scheme is not working correctly). How can I make it work correctly on the new input system as well? Where would I change what here?
Hmm, I haven’t heard about this scenario before that I can recall.
Looking at the code, I find there are two possible things to try.
When Unity receives an input event, like ‘mousedown’ or ‘pointerdown’ or other, it runs an event handler that does a dispatch of the event into the buffered input subsystems, but tries to avoid running a full engine update tick. The buffered input subsystems generally queue the event to be integrated into the input delegates next frame, and to run the C# handler code on the next frame.
So the input event gets queued, and then on the next scheduled engine tick, the game C# code will process all of those events.
Now by that time, we are already out of the original input down event. I wonder how browsers react if one attempts to register an input up event after the down event has already arrived.
Does it change anything if you’d avoid using “once: true”, and always have a permanent event handler registered to ‘pointerup’, that skips behaving as a no-op when it is unnecessary to act?
The other thing that catches my eye is the registration to “document.documentElement”. Unity’s JS code registers input event handlers on either window or the canvas, but not on the documentElement. So maybe there could be something that relates to event propagation that causes the up event not be seen on the documentElement. Unity calls event.preventDefault(); via Emscripten’s touch handler callback code in the framework.js when the touch lands on the canvas element to say “Unity’s got this event, no need to do the browser default action”.
a) Try changing the registration to occur on canvas element if that would be more consistent?
b) Try removing the event.preventDefault() in Emscripten callback code to see if that might be interrupting things.
Sorry, these are a bit of guesses to get poking in the situation, might or might not be relevant to this.