Escape key triggers 'submit' action in the UI action map

Edit: This does seem to be specific to TextMeshPro’s input field. After originally posting and further research, this is relevant to the issue: TextMeshPro onSubmit() being called with escape key

Original post:

Apologies in advance if this has been addressed before, I searched and couldn’t find anything directly relevant.

The observed behavior (symptom): I have a textmesh pro input field, and when it is selected in playmode, pressing the Escape key on the keyboard causes the text to be submitted, just like hitting the Enter key does. To be more specific, I have it wired up as:

[SerializeField] private TMP_InputField inputField;
...
  inputField.onSubmit.AddListener(OnSubmitInput);
...

… where when I press escape, the OnSubmitInput method I have defined is being called.

My question: WHY?

I have been trying to wrap my head around this behavior, of why Escape would be triggering a ‘submit’. The action map being used is the default ‘UI’ action map from the input action asset. In that action map, the “Submit” Action has the binding ‘Submit [any]’.

The manual (UI support | Input System | 1.0.2) states under the ‘Navigation-type input’ section: “…input from submit will trigger ISubmitHandler on the currently selected object and Cancel will trigger ICancelHandler on it.”

And (UI support | Input System | 1.0.2) under the ‘submit’ entry in the table says “An Action to engage with or “click” the currently selected UI selectable. See navigation-type input.”

…which taken at face value, makes sense. What doesn’t make sense to me, though is why the ESCAPE key of all things would be triggering the ‘submit’. This is about as intuitive (to me) as “press cancel to confirm” or the brake increasing speed of the car, or the “off” button turning a device on. Maybe my expectation for what the escape key should do is flawed. I would expect it to trigger a behavior like ‘cancel’ or ‘back’ or something along those lines.

I don’t know how to look further under the hood to see how the ‘submit [any]’ binding is being wired up for ‘escape’, so if anyone has any suggestion about how to explore (and change) this, it would be appreciated.

I don’t want to have to manually re-bind this in the action map, because I appreciate the benefits of the abstraction. I just am having trouble comprehending the observed behavior.

Thanks in advance for any insight into understanding why this is like this, and/or how to change it.

Edit: Followup question: If Escape triggers ‘Submit [Any]’ what will trigger ‘Cancel [Any]’ ?

This sounds more like a potential bug in TMP_InputField. Would you mind filing a ticket with the Unity bug reporter? (“Help >> Report a Bug…” in the editor’s main menu)

The escape key actually doesn’t trigger Submit. I don’t know enough about the implementation of TMP_InputField, but I doubt that either of the two navigation actions here (Submit and Cancel) play into this.

ATM text input in uGUI unfortunately is not driven from the input system. We’re working to remedy that. ATM the text input fields pick up their text inputs directly from IMGUI input events.

Interesting, thank you very much for the reply and for the information. I will do some more digging/testing and see what I can figure out and file a report/update here when I have more detailed information.

Thanks again for the insight that it isn’t the input system driving the text input fields. I posted an edit on the top of the original post with some relevant info regarding escape key and TMP input fields (my research was about the input system so I didn’t find that before posting). Luckily, there is an inputField.wasCancelled that can be used to check for Escape, so I am able to solve the problem in my code without modifying the Input System UI bindings. This solution is from this post ( TextMeshPro onSubmit() being called with escape key ):

[SerializeField] private TMP_InputField inputField;
...
  inputField.onSubmit.AddListener(OnSubmitInput);
...
public void OnSubmitInput(string inputText) {
...
if (inputField.wasCanceled) // apparently this detects that the 'escape' key triggered the OnSubmit event
        {
            return;
        }
...
}

I still find it a little odd that Escape would be set up to trigger TMP_InputField’s OnSubmit event, but I guess they want to leave it up to the user to decide how to handle it. I am looking forward to it being driven by the input system, both so that we have more visibility into what’s really going on as well as better control over it.