EnhancedInput Action Bindings with CommonActivatableWidgets

Our team has recently experienced some difficulties when trying to combine EnhancedInput and CommonUI using Unreal 5.6. We are using the experimental CommonUI-EnhancedInput integration feature and have run into issues specifically regarding binding EnhancedInput actions on ActivatableWidgets and loss of input.

Our Activatable widgets are all placed into a root layout widget containing a set of CommonActivatableWidgetStacks, as seen in Lyra. In some of our widgets we have been using EnhancedInput Action Bindings (non-Generic actions), just as shown in

https://dev.epicgames.com/documentation/en-us/unreal-engine/using-

commonui-with-enhnaced-input-in-unreal-engine.

The problem which we have seen is that for Activatable widgets, this binding only works when the widget is first generated. After a Deactivate/Reactivate event, the input bindings are no longer sending input to the reactivated widget. We also found that deactivated widgets can leave unhandled InputComponents on the input stack for some time, blocking other input handling.

Our workaround was to add the following overrides to a subclass of CommonActivatableWidget. But this isn’t the most optimal solution, particularly as it makes it more difficult for our content creators to set up reliable input events via Blueprint. Is there anything planned around a better way to be able to use EnhancedInput actions together with CommonActivatableWidget?

void UAlternativeCommonActivatableWidget::NativeOnActivated()
{
  Super::NativeOnActivated();
  InitializeInputComponent(); //Reinitialize input component
  InitInputBindings(); //Do any necessary action bindings via C++
}

void UAlternativeCommonActivatableWidget::NativeOnDeactivated()
{
  StopListeningForAllInputActions(); //Deregister InputComponent and mark for garbage cleaning
  Super::NativeOnDeactivated();
}

Steps to Reproduce

Please see description for repro.

Hi,

In a quick test, it looks like the binding fires regardless of activation test. This is what I’d expect, as those input action bindings aren’t inherently bound to the functionality of the widget; I’d expect them to operate independently, and I could check activation state in the response if needed. We do remove/reapply mapping contexts on deactivate/reactivate, if one is set in the details panel. Actual creation/destruction of the input component should be handled at the UserWidget level and tied to NativeOnInitialized (which runs once regardless of how many times the underlying Slate is destroyed/reconstructed) and OnDestroy (tied to destruction of the UObject. Basically, the expectation is for the binding to be persistent across the lifetime of the widget.

Are you able to tell where the mapping is lost? Is the whole input component destroyed, or is it falling down somewhere else? If you’re able to send a minimal repro project, I’m happy to dig around a bit and see if something unexpected is happening. It’s certainly possible that my quick test is set up differently than your project.

Best,

Cody