Bug New Input system listens for click event on whole document instead of canvas

Cross-posting from this thread in the Input System forum https://forum.unity.com/threads/web...re-click-event-listener.1364205/#post-8951610

We've previously filed this bug report https://unity3d.atlassian.net/servicedesk/customer/portal/2/IN-23815, but it was closed since our intern finished their term and wasn't responding to the request for a reproduction.

----

We're trying to migrate from the old UnityEngine.Input system to the new input system and we're having some issues with click detection on WebGL. Our web application runs Unity WebGL in an HTML canvas with additional HTML elements on top of the Unity canvas.

In the old input system, we used Input.GetMouseDown(0) to check if the user is left clicking. The great thing about this approach is that it automatically accounts for the other HTML elements (the ones on top of the Unity canvas). If the user clicks on an HTML element that is not the canvas, Unity would not detect this as a left click. Input.GetMouseDown(0) would only return true if the user clicked on the canvas itself; not on any other element.

For the new input system, we set up an action that is listening to Left Button [Mouse] with a Button action type. Then, in the code we check if the user is left clicking using _input.Player.LeftClick.performed += ... and performing logic whenever that event fires. The problem is that this event fires regardless if the user clicks on the Unity canvas or not. If the user is clicking on an HTML element that is on top of the Unity canvas, the input system will still detect it as a click. This does not match the behaviour of the old input system.

We looked further into the generated WASM to try and figure out what exactly is going on. It looks like the registration function used by Unity for mouse click input is `emscripten_set_mousedown_callback_on_thread`. It seems like it's using a `target` parameter of `2`, which looks like it stands for `document` (screenshot attached).

If instead we substitute that above for $WebGL_UnityCanvasSelector__, this fixes our issue. In other words, it seems feasible to add some configuration to let us choose whether or not we want to register clicks on a `document` level or on a `canvas` level.

Would it be possible to add this configuration to the input system? The hack above isn't feasible for production and there's no good workarounds.

Thanks!

 

I'm having the same behavior as well. Click events with the new input system are triggered on any HTML element, vs the old input system which was just the canvas.

 

I will share a sample repo and screen recording in a moment.

 

Here is video of bug:
https://drive.google.com/file/d/1DoLjG-HsFDptGhFWhft5YXZqi_SafhZQ/view?usp=sharing

 

You can see once the overlay comes up the Old Input object with a click event (sphere) no longer triggers. However the new input system still sporadically is firing click events.

 

Repo: https://github.com/isaacschwab/unity-input-bug-webgl

 

You can run the build from the WebClient folder, just npm install -> npm start

 

I have had issues with 2021.3.23f1 and 2021.3.19f1

 

@unityruba Have you been able to take a look at this yet?

 

Same is happening to me, on a project built with 2022.2 which would otherwise work fine when built with a 2021.3 version.

I have submitted a bug report with repro: incident ID is IN-41716

 

So what is the current status of this? I can reproduce this too and also created a local repro switching between new and old input system. @CiroContns : Do you mean that the bug is related to the Unity version and not to the input system itself? -> I only tested one Unity Version (2022.3.7f1) and Input System 1.6.3.

 

@unityruba

 

I'm having a similar problem here.
For example, in this link, you are supposed to be able to rotate the camera by dragging the mouse inside the canvas.
However, it rotates the camera if you drag the mouse anywhere inside the iframe where the app is running.

https://app-staging-reup.macheight.com/property/1