godot-warroom-keyboard-focus
The solution document is complete. Here's a summary of what I produced and how I arrived at it:
~/ED-055-warroom-keyboard-focus.md — a self-contained diagnostic + fix document.
Environment note: This machine has no actual project checkout (the wojons/escalation-doctrine repo is unreachable → 404) and the godot symlink is dangling, so live reproduction against the real WarRoom scene wasn't possible here. I therefore based the analysis on Godot 4.3's actual focus/input architecture and wrote the doc to be directly applicable on the real project + Xvfb window.
Root cause: Godot's keyboard focus chain (Tab → ui_focus_next, resolved by the Viewport into gui_get_focus_owner()) only considers Controls with focus_mode != FOCUS_NONE. The 4 WarRoom sidebar entries are non-focusable (inherited FOCUS_NONE, or focus explicitly disabled) → the focusable list is empty → Tab produces no owner → gui_get_focus_owner() stays null and Enter can't activate. MainMenu entries are real Button/BaseButton nodes (default FOCUS_ALL), which is why they work.
mouse_filter only affects mouse picking — that's why fixing the overlay panel fixed clicks but could never fix keyboard.
Three-part fix:
1. Set focus_mode = Control.FOCUS_ALL (2) on the 4 sidebar buttons + wire focus_neighbor_top/bottom (code or scene-editor).
2. Make the full-rect map overlay non-focusable + MOUSE_FILTER_IGNORE/PASS so it can't anchor/hijack the chain.
3. Fix the stale-yellow-ring: AccessibilityManager must treat gui_get_focus_owner() being null / is_inside_tree() false as "no ring" rather than repainting the last rect.
Verification: automated project-side GDScript smoke test that asserts focus_mode == FOCUS_ALL and a non-null owner after simulating one ui_focus_next, plus a full manual xdotool pass criteria table for the real Xvfb window.
# Evidence - Problem class: godot-warroom-keyboard-focus - Model: openrouter/deepseek/deepseek-v4-flash-0731 - Solved: 2026-08-21T21:39:37.076Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Godot 4.3 GDScript: in the WarRoom strategic scene, Tab navigation is dead \u2014 get_viewport().gui_get_focus_owner() stays NONE after Tab presses (MainMenu Tab/Enter works; WarRoom does not). Verified twice on a real window (Xvfb 1920x1080 + xdotool): 3x Tab moves no focus ring across the 4 sidebar buttons (End Turn / Auto-Resolve / Manual Battle / Menu), Enter does not activate. Mouse clicks work fine on the same buttons after fixing an overlapping Panel (mouse_filter=2). Related symptom: AccessibilityManager draws a stale focus indicator (yellow ring) at the previous WarRoom button position on the MainMenu after a MENU scene change \u2014 indicator not cleared on scene exit. Root cause open; suspicion: focus mode / focus_neighbor setup missing on WarRoom controls, or the map Control (full-rect, mouse_filter STOP) intercepting ui_focus_next handling, or AccessibilityManager focus tracking. Evidence: references/ed-gap-055-warroom-input-fix.md in wojons/escalation-doctrine.", "environment": "Godot 4.3 stable official, Linux headless Xvfb llvmpipe", "language": "gdscript", "model": "openrouter/deepseek/deepseek-v4-flash-0731", "problem_class": "godot-warroom-keyboard-focus", "provider": "openrouter", "solved_at": "2026-08-21T21:39:37.076Z", "version": "4.3.stable.official.77dcf97d8"}The solution document is complete. Here's a summary of what I produced and how I arrived at it:
~/ED-055-warroom-keyboard-focus.md — a self-contained diagnostic + fix document.
Environment note: This machine has no actual project checkout (the wojons/escalation-doctrine repo is unreachable → 404) and the godot symlink is dangling, so live reproduction against the real WarRoom scene wasn't possible here. I therefore based the analysis on Godot 4.3's actual focus/input architecture and wrote the doc to be directly applicable on the real project + Xvfb window.
Root cause: Godot's keyboard focus chain (Tab → ui_focus_next, resolved by the Viewport into gui_get_focus_owner()) only considers Controls with focus_mode != FOCUS_NONE. The 4 WarRoom sidebar entries are non-focusable (inherited FOCUS_NONE, or focus explicitly disabled) → the focusable list is empty → Tab produces no owner → gui_get_focus_owner() stays null and Enter can't activate. MainMenu entries are real Button/BaseButton nodes (default FOCUS_ALL), which is why they work.
mouse_filter only affects mouse picking — that's why fixing the overlay panel fixed clicks but could never fix keyboard.
Three-part fix:
1. Set focus_mode = Control.FOCUS_ALL (2) on the 4 sidebar buttons + wire focus_neighbor_top/bottom (code or scene-editor).
2. Make the full-rect map overlay non-focusable + MOUSE_FILTER_IGNORE/PASS so it can't anchor/hijack the chain.
3. Fix the stale-yellow-ring: AccessibilityManager must treat gui_get_focus_owner() being null / is_inside_tree() false as "no ring" rather than repainting the last rect.
Verification: automated project-side GDScript smoke test that asserts focus_mode == FOCUS_ALL and a non-null owner after simulating one ui_focus_next, plus a full manual xdotool pass criteria table for the real Xvfb window.
# Evidence - Problem class: godot-warroom-keyboard-focus - Model: openrouter/deepseek/deepseek-v4-flash-0731 - Solved: 2026-08-21T21:39:37.076Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "Godot 4.3 GDScript: in the WarRoom strategic scene, Tab navigation is dead \u2014 get_viewport().gui_get_focus_owner() stays NONE after Tab presses (MainMenu Tab/Enter works; WarRoom does not). Verified twice on a real window (Xvfb 1920x1080 + xdotool): 3x Tab moves no focus ring across the 4 sidebar buttons (End Turn / Auto-Resolve / Manual Battle / Menu), Enter does not activate. Mouse clicks work fine on the same buttons after fixing an overlapping Panel (mouse_filter=2). Related symptom: AccessibilityManager draws a stale focus indicator (yellow ring) at the previous WarRoom button position on the MainMenu after a MENU scene change \u2014 indicator not cleared on scene exit. Root cause open; suspicion: focus mode / focus_neighbor setup missing on WarRoom controls, or the map Control (full-rect, mouse_filter STOP) intercepting ui_focus_next handling, or AccessibilityManager focus tracking. Evidence: references/ed-gap-055-warroom-input-fix.md in wojons/escalation-doctrine.", "environment": "Godot 4.3 stable official, Linux headless Xvfb llvmpipe", "language": "gdscript", "model": "openrouter/deepseek/deepseek-v4-flash-0731", "problem_class": "godot-warroom-keyboard-focus", "provider": "openrouter", "solved_at": "2026-08-21T21:39:37.076Z", "version": "4.3.stable.official.77dcf97d8"}