Why is my CommonUI widget not receiving input in Unreal Engine 5?

The most common cause is that the widget is not properly activated in the CommonUI activation stack. CommonUI uses an activatable widget system where only the topmost activated widget receives input. If your widget was added to the viewport but not activated via ActivateWidget or pushed onto a CommonUI stack, it will not receive input events even though it is visible on screen.

How does CommonUI input routing differ from standard UMG input in UE5?

Standard UMG distributes input to all visible widgets via Slate focus. CommonUI adds an activation layer on top: only the topmost activatable widget in the stack receives input. This means a widget can be visible and focusable but still not receive input because another widget higher in the activation stack is intercepting it. CommonUI also manages game vs menu input mode automatically through its activation system.

Fix: Unreal Common UI Widget Not Receiving Input

Q: What is the difference between CommonUI input actions and Enhanced Input actions in UE5?

CommonUI input actions are defined as data assets (UCommonInputActionDataBase) and are designed for platform-agnostic UI interactions. They display context-sensitive button prompts and route through the CommonUI activation stack. Enhanced Input actions are designed for gameplay input and route through the player controller's input component. The two systems can coexist but should not be mixed for the same input event, as CommonUI actions respect widget activation state while Enhanced Input does not.

Quick answer: The most common cause is that the widget is not properly activated in the CommonUI activation stack. CommonUI uses an activatable widget system where only the topmost activated widget receives input.

Here is how to fix Unreal common UI widget not receiving input. You have built a menu using CommonUI, pushed it to the viewport, and it looks perfect — but buttons do not respond to clicks, gamepad navigation does not work, and none of your bound input actions fire. The widget is visible and seemingly interactive, but it swallows no input at all. CommonUI adds an activation and input routing layer on top of standard UMG that is easy to misconfigure. Here is how to get your widgets responding to input.

The Symptom

You have a widget that inherits from UCommonActivatableWidget (or one of its subclasses). You add it to the viewport or push it onto a widget stack. The widget renders correctly and is visible on screen. But when you click buttons, press gamepad face buttons, or try to navigate with the D-pad, nothing happens. The buttons do not highlight on hover, bound actions do not fire, and the widget appears completely inert.

In some cases, the widget receives mouse input but not gamepad input, or vice versa. In other cases, the widget worked before you added a second layer of UI (like a confirmation dialog) and now neither layer responds. You might also see the widget responding to input briefly after creation but then going dead after another widget is pushed or popped from the stack.

A particularly confusing variant is when the widget receives input in the editor preview (using the UMG Designer play mode) but not during actual gameplay. This is because the editor preview does not use the CommonUI activation system, so widgets that would be blocked at runtime work fine in the designer.

What Causes This

1. The widget is not activated in the CommonUI stack. CommonUI uses an activation model where only the topmost activated widget in a stack receives input. Adding a widget to the viewport does not automatically activate it in CommonUI's system. If you call AddToViewport directly instead of pushing the widget onto a UCommonActivatableWidgetStack, the widget is visible but CommonUI does not know about it and will not route input to it. This is the most frequent cause of unresponsive CommonUI widgets.

2. Input mode mismatch between game and menu. CommonUI manages the input mode (game, menu, or game-and-menu) based on the active widget's configuration. If your widget expects menu input (mouse cursor, UI navigation) but the game is in game-only input mode, the widget will not receive UI events. Conversely, if the widget expects game input but is pushed with menu-only mode, gameplay input will be blocked. The GetDesiredInputConfig override controls this, and getting it wrong means the input mode does not match what your widget needs.

3. Another widget higher in the stack is consuming input. CommonUI's activation stack is a strict hierarchy. When a new widget is pushed on top, the widget below it is deactivated and stops receiving input. If you have a HUD widget that should remain interactive while a dialog is open, but the dialog sits higher in the stack, the HUD loses all input. This is by design in CommonUI but can be unexpected if you are used to standard UMG where all visible widgets can receive input simultaneously.

4. Using Enhanced Input bindings instead of CommonUI input actions. CommonUI has its own input action system separate from Enhanced Input. If you bind a gamepad button via Enhanced Input in your PlayerController but expect it to interact with a CommonUI widget, the two systems will conflict. CommonUI input actions are data assets that route through the activation stack, while Enhanced Input actions route through the player controller's input component. Mixing them causes input to reach the wrong system.

5. Widget activation lifecycle not handled correctly. UCommonActivatableWidget has lifecycle callbacks: NativeOnActivated and NativeOnDeactivated. If your widget does setup work (like binding actions or setting focus) in NativeConstruct instead of NativeOnActivated, the setup may happen before the widget is in the activation stack. Actions bound before activation will not route correctly. Similarly, if you deactivate a widget and reactivate it, any setup done only in NativeConstruct will not re-run.

The Fix

Step 1: Set up your widget as a proper CommonUI activatable widget and push it onto a stack. Instead of adding widgets directly to the viewport, create a root layout widget with a UCommonActivatableWidgetStack and push your menu widgets onto it. This ensures CommonUI manages the activation lifecycle:

// MyHUD.h - Root layout with a widget stack
#pragma once
#include "CoreMinimal.h"
#include "CommonUserWidget.h"
#include "Widgets/CommonActivatableWidgetContainer.h"
#include "MyHUD.generated.h"

UCLASS()
class UMyHUDLayout : public UCommonUserWidget
{
    GENERATED_BODY()

public:
    // Push a widget onto the menu stack
    UFUNCTION(BlueprintCallable)
    UCommonActivatableWidget* PushMenu(
        TSubclassOf<UCommonActivatableWidget> WidgetClass);

protected:
    // Bind this to a CommonActivatableWidgetStack in your UMG layout
    UPROPERTY(BlueprintReadOnly, meta = (BindWidget))
    UCommonActivatableWidgetStack* MenuStack;
};

// MyHUD.cpp
#include "MyHUD.h"

UCommonActivatableWidget* UMyHUDLayout::PushMenu(
    TSubclassOf<UCommonActivatableWidget> WidgetClass)
{
    if (!MenuStack || !WidgetClass)
    {
        UE_LOG(LogTemp, Error,
            TEXT("Cannot push menu: stack or class is null"));
        return nullptr;
    }

    UCommonActivatableWidget* Widget =
        MenuStack->AddWidget<UCommonActivatableWidget>(
            *WidgetClass);

    UE_LOG(LogTemp, Log,
        TEXT("Pushed %s onto menu stack"),
        *WidgetClass->GetName());

    return Widget;
}

The UCommonActivatableWidgetStack automatically activates the pushed widget and deactivates any widget below it. When the top widget is removed (via DeactivateWidget), the widget below it is reactivated and regains input. This stack-based approach is the foundation of CommonUI input routing. If you bypass it by calling AddToViewport directly, the widget exists outside the stack and CommonUI will not route input to it.

Step 2: Configure input routing and game/menu mode transitions. Each activatable widget should declare what kind of input it needs by overriding GetDesiredInputConfig. This tells CommonUI whether to switch to menu mode, keep game input active, or allow both:

// MyMenuWidget.h - A pause menu that wants menu-only input
#pragma once
#include "CoreMinimal.h"
#include "CommonActivatableWidget.h"
#include "MyMenuWidget.generated.h"

UCLASS()
class UMyMenuWidget : public UCommonActivatableWidget
{
    GENERATED_BODY()

protected:
    virtual TOptional<FUIInputConfig>
        GetDesiredInputConfig() const override;

    virtual void NativeOnActivated() override;
    virtual void NativeOnDeactivated() override;
};

// MyMenuWidget.cpp
#include "MyMenuWidget.h"

TOptional<FUIInputConfig>
    UMyMenuWidget::GetDesiredInputConfig() const
{
    // Menu mode: show cursor, enable UI navigation,
    // block game input while this widget is active
    return FUIInputConfig(
        ECommonInputMode::Menu,
        EMouseCaptureMode::NoCapture);
}

void UMyMenuWidget::NativeOnActivated()
{
    Super::NativeOnActivated();

    // Set up input bindings and focus HERE, not in NativeConstruct
    UE_LOG(LogTemp, Log,
        TEXT("Menu activated - now receiving input"));
}

void UMyMenuWidget::NativeOnDeactivated()
{
    Super::NativeOnDeactivated();

    UE_LOG(LogTemp, Log,
        TEXT("Menu deactivated - input routed elsewhere"));
}

The FUIInputConfig returned by GetDesiredInputConfig controls the entire input mode while this widget is the topmost active widget. Use ECommonInputMode::Menu for full UI menus (pauses game input, shows cursor). Use ECommonInputMode::Game for HUD overlays that should not interfere with gameplay. Use ECommonInputMode::All if you need both game input and UI interaction simultaneously. If this method is not overridden, the widget inherits the input mode from whatever was active before, which may not be what you want.

Step 3: Use CommonUI input action bindings for UI-specific inputs. For actions like confirm, cancel, tab switching, or custom UI commands, use CommonUI's input action system instead of Enhanced Input. This ensures the actions respect the activation stack and display the correct platform button prompts:

// MyMenuWidget.cpp - Binding CommonUI input actions
#include "Input/CommonUIInputTypes.h"

void UMyMenuWidget::NativeOnActivated()
{
    Super::NativeOnActivated();

    // Register a back/cancel action using CommonUI data asset
    if (BackInputAction)
    {
        FBindUIActionArgs BindArgs(BackInputAction,
            FSimpleDelegate::CreateUObject(
                this, &UMyMenuWidget::OnBackAction));
        BindArgs.bDisplayInActionBar = true;

        BackActionHandle = RegisterUIActionBinding(BindArgs);

        UE_LOG(LogTemp, Log,
            TEXT("Registered back action on menu widget"));
    }

    // Register a tab-switch action
    if (TabNextInputAction)
    {
        FBindUIActionArgs TabArgs(TabNextInputAction,
            FSimpleDelegate::CreateUObject(
                this, &UMyMenuWidget::OnTabNext));
        TabArgs.bDisplayInActionBar = true;

        TabActionHandle = RegisterUIActionBinding(TabArgs);
    }
}

void UMyMenuWidget::OnBackAction()
{
    UE_LOG(LogTemp, Log,
        TEXT("Back action received - deactivating menu"));
    DeactivateWidget();
}

void UMyMenuWidget::OnTabNext()
{
    UE_LOG(LogTemp, Log,
        TEXT("Tab next action received"));
    // Switch to next tab in your tab control
}

void UMyMenuWidget::NativeOnDeactivated()
{
    // Action bindings registered via RegisterUIActionBinding
    // are automatically cleaned up on deactivation
    Super::NativeOnDeactivated();
}

The key difference between CommonUI input actions and Enhanced Input is scope. CommonUI actions only fire when the widget that registered them is the active widget in the stack. If another widget is pushed on top, the bindings are suspended until that widget is removed. Enhanced Input actions bypass this entirely and fire regardless of UI state, which is why mixing the two systems for UI interactions causes problems. Use CommonUI actions for all UI-related input and reserve Enhanced Input for gameplay actions that should work independently of the UI state.

Related Issues

If your CommonUI widget receives mouse input but not gamepad input, check that the CommonInputBaseControllerData is configured correctly for your target gamepad in Project Settings under Common Input. Each controller type needs a data asset that maps physical buttons to CommonUI actions. If the data asset is missing for a controller type, that controller will not generate CommonUI input events even though Enhanced Input works fine with it.

If widgets respond to input after first creation but stop working after being deactivated and reactivated, make sure all input setup happens in NativeOnActivated rather than NativeConstruct. NativeConstruct is called only once when the widget is first created, but NativeOnActivated is called every time the widget becomes the active widget in the stack. Focus management should also happen in NativeOnActivated — call SetFocus on your desired initial button after activation so gamepad navigation has a starting point.

If the widget is visible but dead to input, it is not activated in the CommonUI stack. Push it onto a UCommonActivatableWidgetStack instead of calling AddToViewport.