If you press the interact button during any animation being played on a CommonActivateableWidget the system seems to lose track of which widget is intended to be focused. This creates a soft lock when using a gamepad that can only be resolved by using the mouse to re-focus the UI with a hover or click event.
I first noticed this issue in 5.5, but I’ve been able to reproduce this Soft Lock issue in 5.3, 5.4, 5.5, and now 5.6. It is very easy to reproduce on any UI that has a transition animation that’s longer then a few frames. I haven’t found any way to work around this issue other then to remove all transition animations from all our UI, which is not ideal.
P.S. Please let us know if we should no longer be using CommonUI going forward. There are a number of issues we’ve been experiencing with the plug-in for a while, it seems that its been in beta for two years, and no bug fixes or support have been implements in UE 5.6 for this system so the UI team is a getting concerned. 
Any help or guidance would be greatly appreciated.
Steps to Reproduce
- Open the “Content Example” Project in 5.4, 5.5, or 5.6.
- Open the following map in the editor : CommonUI
- Plug in a game controller
- Walk over to the first station labeled “1.1 Activatable Widgets”
- Once the “Widget Activation allows…” UI is displayed on screen highlight any of the buttons labeled “Click Me!”
- Press the bottom face button twice (i.e Double-Tap “A” on an XBox Controller or “X” on a playstation controller)
Observed:
The UI can no longer be interacted with using the controller. When playing from the editor, moving the thumb stick will cause various docked slate editor windows to become selected. If playing in a packaged Ship or Development build the controller can no longer be used to interact with the UI, but no other issues are present.
Using Shift + F1 can release the softlock, but the cursor is frequently not displayed and can make exiting the UI exceptionally difficult.
This occurs if an input is registered during an animation while using common UI activateable widgets. That includes animations triggered through script like in the CommonUI example map described in the repro steps, as well as the automated TransitionDuration animations for fading in a UI when added to a UCommonActivatableWidgetContainerBase , or cycling through widget switcher elements using the UCommonAnimatedSwitcher.
Hi,
I investigated the behaviour you reported and found what was happening is that during the beginning of the animation, the focused widget is outside the bounds of the viewport so the virtual cursor that CommonUI uses cannot properly hover the focused widget. When pressing the bottom face button, CommonUI simulates a left mouse button press to activate the button, so the clicks were not making. With the simulated click feature disabled, the button is focused and handles the bottom face button press properly and the issue no longer happens, another option could be to disable input during the animation but that may not align with your desired UX.
The simulated click functionality can be disabled by either overriding FCommonAnalogCursor::ShouldVirtualAcceptSimulateMouseButton to return false (in 5.5+) or setting the CVar CommonUI.ShouldVirtualAcceptSimulateMouseButton to false (5.6).
As for any other issues you’ve been running into with CommonUI, please let us know about them so we can look into them. Unreal 5.6 will have many improvements and fixes for CommonUI as well.
Thank you very much for the suggestions Dylan! We’ll look at solutions for blocking input during these animations for now. 
Good to know that Common UI is still getting support! I’ll see what I can do to isolate the other issues the team has been seeing and getting them reported. 
Thanks again!