Quick answer: Verify the Widget Component has collision enabled on the same channel the Widget Interaction Component traces on (usually Visibility), set the Interaction Distance to be greater than the distance to the widget, and make sure you’re calling PressPointerKey(EKeys::LeftMouseButton) — not just sending an input action.
You’ve placed a Widget Component in your 3D world — maybe a terminal screen, a floating health bar with an interact button, or a VR menu — and added a Widget Interaction Component to your player. The debug line shows it’s pointing at the widget. But when you press your interact key, nothing happens. The button doesn’t highlight, doesn’t click, doesn’t respond at all. This is one of the trickiest Unreal UI issues because the system involves several components that must all be configured in agreement.
How Widget Interaction Works
The Widget Interaction Component works by performing a line trace (raycast) each frame from its world position along its forward vector. When the trace hits a Widget Component, the interaction system translates the hit location into 2D coordinates on the widget’s surface and generates simulated mouse events (hover, press, release) that the UMG widget tree processes just like regular mouse input.
This means several things must be true simultaneously:
- The line trace must actually hit the Widget Component (collision channel, distance, angle).
- The Widget Component must receive the interaction (collision enabled, correct channel response).
- The simulated mouse events must be triggered (PressPointerKey/ReleasePointerKey calls).
- The UMG widget must be interactive (buttons must be enabled, hit-testable).
A failure in any one of these steps means no response, and the engine gives you very little feedback about which step failed.
Collision Channel Configuration
This is the most common failure point. The Widget Interaction Component has a Trace Channel property (default: Visibility). The Widget Component has a Collision section with its own presets. These must match.
On the Widget Component (the one displaying your UI in 3D):
- In the Details panel, find the Collision section.
- Set Collision Presets to “Custom.”
- Set Collision Enabled to “Query Only (No Physics Collision).”
- Under Collision Responses, set the Visibility channel to Block.
On the Widget Interaction Component (attached to your player/controller):
- Verify Trace Channel is set to Visibility (or whatever channel your Widget Component blocks).
- Set Interaction Distance to a value large enough to reach the widget. The default of 500 units works for nearby widgets, but for a terminal across a room, you may need 1000+.
If you’re using a custom trace channel for widget interaction (recommended for complex projects to avoid conflicts with other visibility traces), make sure both components reference the same custom channel:
// In your project's DefaultEngine.ini, define a custom channel:
[/Script/Engine.CollisionProfile]
+DefaultChannelResponses=(Channel=ECC_GameTraceChannel1,
DefaultResponse=ECR_Ignore,
bTraceType=True,
bStaticObject=False,
Name="WidgetInteraction")
Then set the Widget Interaction Component’s Trace Channel to your custom channel and the Widget Component’s collision response to Block on that channel.
Triggering Press and Release Events
The Widget Interaction Component does not automatically click when the player presses a key. You must explicitly call PressPointerKey and ReleasePointerKey in your input handling code. This is not a regular input binding — it’s a function call on the component itself.
In Blueprints:
- In your player controller or pawn Blueprint, handle your input action (e.g., “Interact”).
- On the Pressed event, get a reference to the Widget Interaction Component and call Press Pointer Key with the key set to Left Mouse Button.
- On the Released event, call Release Pointer Key with the same key.
In C++:
void AMyPlayerPawn::SetupPlayerInputComponent(UInputComponent* PlayerInputComponent)
{
Super::SetupPlayerInputComponent(PlayerInputComponent);
// Enhanced Input
if (UEnhancedInputComponent* EnhancedInput =
Cast<UEnhancedInputComponent>(PlayerInputComponent))
{
EnhancedInput->BindAction(InteractAction, ETriggerEvent::Started,
this, &AMyPlayerPawn::OnInteractPressed);
EnhancedInput->BindAction(InteractAction, ETriggerEvent::Completed,
this, &AMyPlayerPawn::OnInteractReleased);
}
}
void AMyPlayerPawn::OnInteractPressed()
{
if (WidgetInteractionComp)
{
WidgetInteractionComp->PressPointerKey(EKeys::LeftMouseButton);
}
}
void AMyPlayerPawn::OnInteractReleased()
{
if (WidgetInteractionComp)
{
WidgetInteractionComp->ReleasePointerKey(EKeys::LeftMouseButton);
}
}
A common mistake is calling PressPointerKey with the wrong key. UMG buttons respond to EKeys::LeftMouseButton by default. If you pass your gamepad button or a custom key, the button won’t recognize it as a click.
Widget-Side Requirements
Even if the trace hits and the press event fires, the UMG widget itself must be configured to receive interaction:
- Visibility: The button (or any interactive widget) must have its Visibility set to Visible or Self Hit Test Visible, not “Not Hit-Testable” or “Hidden.”
- Is Enabled: The button must not be disabled. A disabled button swallows the hit test but doesn’t fire click events.
- Z-Order: If another widget (like a transparent overlay) is on top of the button, it may intercept the hit test. Check for invisible elements covering the button in your widget hierarchy.
- Focus: In some UMG configurations, buttons require focus to click. The Widget Interaction Component normally handles focus automatically, but custom focus navigation logic can interfere.
Debugging the Interaction
Enable the Widget Interaction Component’s debug visualization to see exactly what’s happening:
// Enable debug in C++
WidgetInteractionComp->bShowDebug = true;
// Or set "Show Debug" to true in the Details panel in the editor
The debug visualization shows:
- A red line extending from the component along the trace direction. If you don’t see this line, the component isn’t active or isn’t ticking.
- A red dot at the hit point when the trace hits a widget. No dot means no hit — check collision channels and distance.
- The hovered widget name in debug text. If this shows “None” even though the dot is on the widget, the Widget Component’s collision is misconfigured.
You can also check the interaction state in code to narrow down the problem:
// Debug logging to find the failure point
void AMyPlayerPawn::OnInteractPressed()
{
if (!WidgetInteractionComp)
{
UE_LOG(LogTemp, Error, TEXT("No WidgetInteractionComp"));
return;
}
FHitResult Hit = WidgetInteractionComp->GetLastHitResult();
UE_LOG(LogTemp, Log, TEXT("Hit Actor: %s"),
Hit.GetActor() ? *Hit.GetActor()->GetName() : TEXT("None"));
UWidget* Hovered = WidgetInteractionComp->GetHoveredWidgetComponent()
? WidgetInteractionComp->GetHoveredWidgetComponent()->GetWidget()
: nullptr;
UE_LOG(LogTemp, Log, TEXT("Hovered widget: %s"),
Hovered ? *Hovered->GetName() : TEXT("None"));
WidgetInteractionComp->PressPointerKey(EKeys::LeftMouseButton);
}
This logging will tell you exactly where the chain breaks: no hit actor means a collision problem, a hit actor but no hovered widget means the Widget Component isn’t properly forwarding the hit, and a hovered widget with no click response means the UMG button itself has an issue.
Widget Interaction works like a virtual laser pointer — the laser has to hit the widget, and then you have to “click” it with PressPointerKey. Neither step happens automatically.