UI Input Module: Cancel and Submit on release instead of press

Unity Engine
,
1

I just updated to version 1.1.1 mainly because I wanted this change from 1.1.0-preview.2:

The submit and the cancel actions of the UI input module now trigger on release instead of press. This makes the behavior consistent with clicks triggering UI response on release rather than press.

However, this is not true, the submit and cancel actions events are still sent on press instead of release in my UI. Thinking that this change maybe only affects the deafult actions asset, I explicitly added Press interactions to my Submit and Cancel actions and set them to Release Only, and double-checked that the actions are correctly linked in the UI input module. Still, these actions are triggered on press.

Is there anything special I need to do after updating?

2

I created a minimal project as a sanity check, it’s attached (created with Unity 2021.1 and Input System 1.1.1).

The SampleScene consists of simply a button that is the first selection, and I put a Debug.Log in the OnClick event handler. When you run the scene and simply press and hold Enter without releasing, you will see that the click event is triggered, which means that the submit action has been triggered on press and not release.

So yeah, am I doing anything wrong?

7604407–944212–InputSystemSanity.zip (23.1 KB)

3

To conclude my monologue, I manually switched to 1.1.0-preview.2 via the package manager and there it works as advertised. It also works in 1.1.0-pre.5, but in 1.1.0-pre.6 it’s reacting to press again instead of release, so whatever happened in the update to preview 6 undid the change of preview 2.

I’m filing a bug report for this now.

4

I am also looking for this functionality. Is it possible to post the link to the bug report so I can follow it?

5

Will share it once it’s public!

6

Just wondering if it ever made it through QA :wink:

7

Nope, laying there open with no reaction after one month. :frowning:

1 Like
8

This bug persists in the new version 1.3.0. I added that to my report, but it still hasn’t been reviewed after 2 1/2 months.

9

Ugh…this is frustrating :frowning: Thanks for the update!

10

There’s finally an answer, but it really puzzles me:

I asked back immediately and am awaiting a response now:

  • Why was the change from 1.1.0-pre.2 reverted?
  • Why wasn’t that mentioned in the 1.1.0-pre.6 release notes?
  • How do we get behaviour consistent with mouse clicks, which still trigger submission events on release rather than press?
11

Thanks for the update! Hope they add the option back :frowning:

12

Well, doesn’t look like it:

13

Dang. Thanks for the update :slight_smile:

14

It seems this issue persists for Unity InputSystem 1.4.2. This sucks because I even found the source of the problem. I can’t change it because it’s a package and I don’t really want to put this into my Assets Folder.

This right here is the problem:

protected bool SendSubmitEventToSelectedObject()
{
    if (eventSystem.currentSelectedGameObject == null)
        return false;

        var data = GetBaseEventData();
    if (input.GetButtonDown(m_SubmitButton))
        ExecuteEvents.Execute(eventSystem.currentSelectedGameObject, data, ExecuteEvents.submitHandler);

    if (input.GetButtonDown(m_CancelButton))
        ExecuteEvents.Execute(eventSystem.currentSelectedGameObject, data, ExecuteEvents.cancelHandler);
    return data.used;
}

It’s a really simple fix too. You just have to change it from GetButtonDown to GetButtonUp in the GetButtonDown Method that is found in a script called BaseInput. Although if it were up to me I would just make another method that detects when the button is Up and use that method instead. Other scripts could be using this method.

public virtual bool GetButtonDown(string buttonName)
{
    return Input.GetButtonDown(buttonName);
}
15

Seems to still persist on 1.4.4. So sad.

16

From what I understand there is no issue officially. They introduced the change in one preview and reverted it in another because they felt it was a bad idea, so I guess the case is closed, and I wouldn’t waste any hope that it’s ever going to be changed again.

I guess if you want the different behaviour, you’ll have to make that change in the source code. At least the packages are open source so this can be done.