For context we’re using the Common UI plugin and Enhanced Input plugin’s
Recently I’ve been looking into an issue that we’ve had where, upon opening an activatable widget that supports focus, would flush the player’s pressed keys. Subsequent pressed of movement keys would allow the player to continue moving. This also happened if the player was moving while trying to click/drag a widget on the screen too, after the click/drag they would be able to move normally again. I also managed to replicate this in the Lyra project under the Inventory Test experience.
The investigation led me to find that the keys are being flushed by UGameViewportClient::LostFocus checking if UInputSettings::bShouldFlushPressedKeysOnViewportFocusLost or APlayerController::bShouldFlushInputWhenViewportFocusChanges is true. The former can be toggled off in the project settings but the player controller’s bool is private so can’t be changed from derived classes constructor, and can only be change from calling APlayerController::SetInputMode with FInputModeGameAndUI.
From what I’ve seen, if you’re using the Common UI plugin, UCommonUIActionRouterBase handles the input config updates for activatable widgets but doesn’t set the input mode for the player controller so we can’t prevent the flushing of pressed keys.
The fix we’ve currently implemented is that when GetDesiredInputConfig is called, we call PlayerController::SetInputMode based on whatever the returned FUIInputConfig’s input mode is set to (All = GameAndUI, Game = GameOnly, Menu = UIOnly), but this doesn’t feel like the best way to handle it because if we ever get into a position where we no longer have an widget activated, the previous config’s SetInputMode will be in effect.
Should we be using SetInputMode at all? Is there another place we should be looking to prevent flushing pressed keys when we want the input mode to be ECommonInput::All?
[Attachment Removed]