Fix: Unreal Input Action Consumed by UI

Here is how to fix Unreal input actions being consumed by UI. You open an inventory menu or HUD overlay. Suddenly WASD stops moving the character, mouse look freezes, and gameplay input is dead. Close the widget and everything works again. Unreal’s input system has a priority chain — UI widgets can intercept and consume input events before they reach the game — and the input mode settings control which layer gets priority.

The Symptom

Gameplay input (movement, camera, actions) stops working when a UMG widget is visible. The character is unresponsive. Closing or removing the widget restores input. The widget itself may or may not be interactive — even a passive HUD overlay can block input if configured incorrectly.

Variant: mouse input works but keyboard does not (or vice versa). Or input works initially but stops after clicking on a UI element. Or the Escape key works but nothing else does.

What Causes This

SetInputModeUIOnly called when showing widget. This is the most common cause. SetInputModeUIOnly routes all input exclusively to the UI layer. No input reaches the PlayerController or Pawn. Developers call this when opening menus, forgetting to switch back or use the combined mode.

Widget is focusable and captures keyboard. A widget with bIsFocusable = true can capture keyboard focus. Once focused, keyboard events go to the widget first. If the widget handles (consumes) the event, the game never sees it. Text input fields, editable combo boxes, and custom widgets often have this enabled.

Widget visibility set to Visible instead of HitTestInvisible. Widgets set to Visible participate in hit testing — they intercept mouse clicks and hovers. For overlay elements (health bars, minimaps, damage indicators) that should display but not intercept input, HitTestInvisible or SelfHitTestInvisible is correct.

Input mode not restored after closing widget. Opening a menu with SetInputModeUIOnly and closing it without calling SetInputModeGameOnly leaves the input mode stuck on UI. The widget is gone but input is still routed to the (now empty) UI layer.

The Fix

Step 1: Use the correct input mode when showing widgets.

// For overlay HUD — game input still works
void AMyPlayerController::ShowHUD()
{
    HUDWidget = CreateWidget<UUserWidget>(this, HUDClass);
    HUDWidget->AddToViewport();
    // No input mode change needed — game input is default
}

// For interactive menu — cursor visible, game still responds
void AMyPlayerController::OpenInventory()
{
    InventoryWidget = CreateWidget<UUserWidget>(this, InventoryClass);
    InventoryWidget->AddToViewport();

    FInputModeGameAndUI InputMode;
    InputMode.SetWidgetToFocus(InventoryWidget->TakeWidget());
    InputMode.SetLockMouseToViewportBehavior(EMouseLockMode::DoNotLock);
    SetInputMode(InputMode);
    SetShowMouseCursor(true);
}

FInputModeGameAndUI allows clicking on UI widgets while forwarding unhandled input to the game. The character can still move while the inventory is open — which may or may not be desired. For a full pause menu, SetInputModeUIOnly is correct but you must restore input on close.

Step 2: Restore input mode when closing widgets.

void AMyPlayerController::CloseInventory()
{
    if (InventoryWidget)
    {
        InventoryWidget->RemoveFromParent();
        InventoryWidget = nullptr;
    }

    FInputModeGameOnly InputMode;
    SetInputMode(InputMode);
    SetShowMouseCursor(false);
}

Always pair input mode changes. If OpenInventory sets GameAndUI, CloseInventory sets GameOnly. Missing the restore is the most common cause of “input died after closing a menu.”

Step 3: Set widget visibility correctly. For HUD elements that should never intercept input:

// In Blueprint: set root widget visibility to Hit Test Invisible
// In C++:
HUDWidget->SetVisibility(ESlateVisibility::HitTestInvisible);

Visibility options:

• Visible: Rendered and intercepts mouse input (hit testing)
• HitTestInvisible: Rendered but does not intercept input, and neither do children
• SelfHitTestInvisible: This widget does not intercept, but children can
• Collapsed / Hidden: Not rendered, no input

Step 4: Manage keyboard focus explicitly. If a widget grabs keyboard focus and you want to release it:

// Release focus from UI back to game
FSlateApplication::Get().SetAllUserFocusToGameViewport();

// Or set focus to a specific widget
InventoryWidget->SetKeyboardFocus();

Enhanced Input and UI Coexistence

With Enhanced Input (UE5), input actions have a bConsumeInput flag. If a UI-bound action consumes input, the gameplay mapping context never sees it:

// In your input mapping context, set priority
// Higher priority contexts are evaluated first
EnhancedInputComp->BindAction(
    MoveAction, ETriggerEvent::Triggered,
    this, &AMyPawn::Move);

// UI mapping context at lower priority
Subsystem->AddMappingContext(UIMappingContext, 0);
Subsystem->AddMappingContext(GameplayMappingContext, 1);
// Higher number = higher priority

Use mapping context priorities to ensure gameplay input takes precedence over UI input. Remove and re-add contexts when switching between gameplay and menu states.

“SetInputModeGameAndUI for overlays. SetInputModeUIOnly for menus. Always restore to GameOnly on close.”

Related Issues

For Enhanced Input binding issues, see Enhanced Input Action Not Firing. For general actor input handling, Actor Replication Not Working covers related multiplayer input patterns.

GameAndUI for interactive overlays. Restore input mode on close. HitTestInvisible for passive HUD elements. Input flows again.