Summary
The Common UI plugin does not properly consume Hold inputs. Specifically, it is only consumed on the first tick of input (when all of the Hold-related bookkeeping gets initialized) and on the last tick (when the Hold duration has been met). On all intermediate ticks, the input is NOT being consumed even though the Hold itself is still in progress.
When in Game+UI input mode, this means that any UI Hold input that matches a game input (e.g. “Press X to Jump”, but also “Hold X for 2 seconds to activate a HUD element”) will trigger BOTH instead of just the Hold.
FUIActionBinding::UpdateHold() and FActionRouterBindingCollection::ProcessHoldInput() work together to decide if a Hold is consumed. If UpdateHold() returns TRUE, ProcessHoldInput() marks the input as “handled” and it is consumed. If UpdateHold() returns FALSE, the input is not consumed.
The source of the issue is that UpdateHold() only returns TRUE on the final tick, once the Hold duration has been met. On every intermediate tick, it returns FALSE.
If you change UpdateHold() to always return TRUE, then the intermediate ticks get consumed (same as the first and last ticks), and the expected behavior is restored.
What Type of Bug are you experiencing?
UI / Tools
Steps to Reproduce
- Set up a Game input (e.g. press X to jump)
- Set up a Common UI input using the same source (e.g. hold X for 2 seconds to quit the game)
- Set up a widget with a Common Button and assign the Hold input to it.
- Launch the game and begin the Hold input.
Expected Result
Hold input is consumed, and non-Hold input is not activated during the Hold.
Observed Result
Hold input is not consumed. Both Hold and non-Hold inputs are activated.
Affects Versions
5.8
Platform(s)
Windows