When I add a new Enhanced Input Context, a priorly pressed button keeps triggering Start and Completed actions indefinitely

[Tuerer]

Basically the title.

I have an input action for Use, which is bound to E in the Input Context.

If E is held down when the context is added to the input subsystem, it starts triggering its Started and Completed functions one after another indefinitely until it’s released or another key is pressed (surprisingly, any key, even if it’s not used for any binding).

The Triggered is fired too, and this I would understand (even though bIgnoreAllPressedKeysUntilRelease is set to true, but okay), but I can’t figure out why Started and Completed keep firing.

Has someone encountered anything like it?

Thank you!

[Everynone]

Is this specifically about transitioning from lower to higher context priority while a key is down?

[Tuerer]

Forgot to mention: when I’m adding a context with a higher priority, everything seems fine.

In this case I add one context and remove the other, all with priority 0.

Basically, I switch between game inputs and UI inputs, and I do it this way because there are a lot more game inputs than UI inputs, and to simply use a context with a higher priority would mean I’d have to override all the bindings of the game context, which seems unnecessary.

The order of adding a new context and removing the old one doesn’t make a difference.

[Tuerer]

Correction: nope, even simply adding an additional context with the higher priority doesn’t help, the Started and Completed are still being triggered.

[Dr_Loveless]

if you begin by acting very intelligent, that will help the problem

then answer it no matter what

[Everynone]

Bear with me as I try to wrap my head around it. This is my IA with Pressed & Released triggers:

As I switch between same priority mapping contexts, only the Ongoing keeps firing, which seems fine.

---

With IA triggers removed completely:

The Triggered persists. I’d like to think believe this is correct behaviour, too. What is the trigger setup on your IA?

---

Or, or, do tell if I am even trying to figure out the right thing! I feel your case is a tad more complex? I also get identical behaviour with:

[Tuerer]

The way it works in your system is what I would expect.

In my case with one additional context it works fine, but wrong with the other. I’ll have to experiment some more and determine why that one context triggers such abhorrent behaviour and I’ll come back when I’ve found something.

[Tuerer]

I’ve narrowed it down a little.

Turns out this happens not because of adding a context, but actually because of some of my widgets.

So my test setup is:

• A brand new Context with a brand new InputAction, not used anywhere else;
• A delay that creates a widget and adds it to viewport (the delay is needed because if I simply create a widget with a keypress, this keypress may affect the issue);
• I press the key that starts the delay, and then press and hold the key assigned to the new InputAction in the new Context;
• My widget appears, but it’s still okay, nothing weird happens;
• Then after another delay, I set focus to the newly created widget. And only after focus, the Started and Completed of the new InputAction start triggering like crazy.

I tried doing the same with a fresh test widget, and couldn’t reproduce it. I tried stripping down the widget that does cause the issue to its bare minumum, deleted all functions and changed its parent class to UserWidget, but the issue still persists.

I feel lost here =)

[Tuerer]

Okay, I dug deeper into the engine code and seem to have found the issue.

The thing is, if you have a focusable widget and it’s being focused, something else gets unfocused, which eventually results in calling FlushPressedKeys() in PlayerController.cpp and PlayerInput.cpp, and for some reason it starts triggering this weird behavior as described in the first message.

You can easily reproduce the issue as follows:

1. Create an empty widget class derived from UserWidget and set its IsFocusable flag to true;
2. Create a mapping context and an input action, add the action to the context;
3. This is the BP setup:
   
   
4. Press and release the key that triggers the delay, then press and hold the key that was bound to the action in the mapping context;
5. Once the delay is over and the created widget is focused, this is the result:
   

If you set IsFocusable to false, this doesn’t happen.