Input focus and keyboard-event tracing

2026-10-06, UE5.6.1 Win64 DX11, automated native-window keyboard/mouse. This is not physical controller/touch proof.

The input observer's relevance test now accepts the owning player's cached IFRootLayout focus path as well as SViewport focus/capture. Player UI overlays can own focus outside SViewport's direct path. Controller/user filtering and active-application checks remain. The observer still returns false and does not consume keys. LogInterfaceForgeInput Verbose records presentation enum changes (Pointer0, Keyboard1, Gamepad2, Touch3); VeryVerbose adds relevance/repeat flags without recording typed characters.

Build-RootFocusInput-UE56 passed. Actual saved Main Down navigated Settings and logged relevance1, Pointer0→Keyboard1. Pointer Quit opened saved WBP_ForgeConfirmation and logged1→0. Right navigated custom Confirm and logged0→1; Escape cancelled and restored Main Quit focus. Pointer Begin entered the saved HUD; G logged relevant1 and0→1, with keyboard Patrol styling and parked mouse no competing emphasis. Screenshot: Visual/RootFocusInput-BlueprintModal-Keyboard-UE56.jpg. RootFocusInput-Runtime-UE56 ended cleanly; no Fatal/Error/Accessed None/Ensure matches.

Automated G did not activate SelectNext, matching archived E observations. Added an opt-in non-shipping example trace IFVerifyWindowInput, then repeated G with the HUD focused. Logs/WindowInputTrace-Runtime-UE56.log records G Pressed (event0) and Released (event1) on the same frame763, 2ms apart, both inside the player controller. Thus this particular pulse did reach the controller; it did not start the Enhanced Input action. Frame-based action evaluation of this short automation pulse is a possible explanation, not a physical-keyboard result. That run exited cleanly without error/ensure matches.

An opt-in non-shipping IFVerifySlateInput fixture now routes the current registered key through FSlateApplication's key-down/up processing, holding it for120ms; existing IFVerifyInput still routes directly to the controller. Both use the example's external gameplay adapter, and neither is a physical-device test. Source build passed (Build-SlateInputFixture-Guard-UE56.log). The Slate fixture was launched at800×600, but a user window occluded the sample before Begin was invoked; native input stopped. No sustained Slate fixture runtime result yet. The current own editor-game is left on Main without injected test input. See Logs/SlateInputFixture-Runtime-UE56.log. Do not rebuild its loaded DLLs until that session is closed normally.

Next: run the held Slate event with proper foreground/focus, inspect Scout1→2 and routing/dispatch logs, then exercise applied remap and packaged revision. Physical held keys, controller/touch/disconnect/drift, extra local players and platform gates remain open. Previous direct-controller fixtures are separate evidence and do not replace these tests.

The pending test subsequently ran in the actual foreground game window. Clicking Begin opened the saved HUD, then the120ms Slate fixture resolved the persisted G mapping. G down reached the player controller on frame243, Enhanced Input SelectNext dispatched on244, G release arrived on304. Visible Scout1→2 and keyboard Patrol focus matched the event logs. Capture: Visual/SlateHeldInput-Scout2-UE56.jpg. Clean exit/no Fatal/Error/Accessed None/Ensure matches. This tests the Slate→viewport→controller→Enhanced Input route with the current remap; it does not prove physical input, packaged latest code or popup-held-key edge cases.