Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Question New Input System problem

Discussion in 'Web' started by Marks4, Oct 26, 2022.

  1. Marks4

    Marks4

    Joined:
    Feb 25, 2018
    Posts:
    563
    @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!
     
  2. brendanduncan_u3d

    brendanduncan_u3d

    Unity Technologies

    Joined:
    Jul 30, 2019
    Posts:
    462
    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.
     
  3. Marks4

    Marks4

    Joined:
    Feb 25, 2018
    Posts:
    563
    I am not sure what you mean. Here's an example of how it currently works on my free FullscreenWebGL plugin.

    Code (JavaScript):
    1. requestFullscreen_FullscreenWebGL: function(callback, option) {
    2.         option = UTF8ToString(option);
    3.         document.documentElement.addEventListener('pointerup', function() {
    4.             const canvas = document.getElementsByTagName("canvas")[0];
    5.             const requestFullscreen = canvas.requestFullscreen.bind(canvas) || canvas.mozRequestFullScreen.bind(canvas) || canvas.webkitRequestFullScreen.bind(canvas) || canvas.msRequestFullscreen.bind(canvas);
    6.             requestFullscreen({ navigationUI: option }).then(function() {
    7.                 callback !== 0 && Module.dynCall_vi(callback, 0);//success
    8.             }).catch(function(error) {
    9.                 callback !== 0 && Module.dynCall_vi(callback, 1);
    10.                 console.error(error);
    11.             });
    12.         }, { once: true });
    13.     },
    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?
     
  4. brendanduncan_u3d

    brendanduncan_u3d

    Unity Technologies

    Joined:
    Jul 30, 2019
    Posts:
    462
    I see. I'll take a look to see why the new input system might not be working. I would expect it should.
     
  5. Marks4

    Marks4

    Joined:
    Feb 25, 2018
    Posts:
    563
  6. jukka_j

    jukka_j

    Unity Technologies

    Joined:
    May 4, 2018
    Posts:
    953
    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.

    1) 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?

    2) 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.
     
    Marks4 likes this.