The following code in UPlayerInput::GetChordsForKeyMapping is at fault for this: 

!(KeyMapping.bAlt || KeyMapping.bCtrl || KeyMapping.bShift || KeyMapping.bCmd || ActionBinding.KeyEvent == EInputEvent::IE_DoubleClick)

This code was originally put in to purposefully allow keys that may not have had their modifiers pressed to be processed because if they were not processed it could block lower priority input keys from components on other frames.


I think that the steps described above would come up more often than the problem that was originally being fixed here (not to mention the code itself is ancient and something may have changed), so it may be worth reconsidering if this is still needed in a modern UE. 

Steps to Reproduce
  1. An Action binding exist for a key (say space bar with no modifiers) for both the pressed and released events.
  2. That key is pressed and held. The press event gets consumed by the binding.
  3. A widget is opened that adds another binding for the same key at a higher priority layer, this time for only the pressed binding (also no modifiers.
  4. The held key is released.
  5. Due to the code in section 2, the event is consumed by the widget's pressed action binding instead of continuing to the actual released binding that existed in step 1. Furthermore, even though the event is consumed, the action biding for pressed isn't actually triggered because a matching chord wasn't found.

This behavior feels incorrect to me since a non-matching binding consumes the event without doing anything, instead of letting a valid matching binding consume the event.

Have Comments or More Details?

There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-133181 in the post.

Login to Vote

ComponentUE - Gameplay - Input
Affects Versions4.255.0
CreatedOct 29, 2021
UpdatedMay 11, 2022
View Jira Issue