Problem
When an engine-drawn context menu opens on GTK (editor … action menu, tab right-click menu, editor right-click menu), keyboard navigation is dead:
j / k / Down / Up don't move selection.Enter doesn't activate.Escape doesn't dismiss.
After clicking inside the menu (anywhere — even a non-clickable separator), all keys start working as expected.
Root cause
src/gtk/mod.rs:5138-5180+ has the right key-handler dispatch (Esc/Enter/j/k/Down/Up) routed to engine methods. The dispatch lives on the editor DrawingArea's key event controller, so it only fires when the DA has keyboard focus.
Opening a context menu (via right-click or via the … button click) doesn't currently call grab_focus() on the editor DA. If focus was elsewhere (e.g. on a sidebar widget, the omnibar, or no widget) when the right-click happened, keys never reach the DA's handler.
Clicking inside the menu sends the click to the DA, which incidentally claims focus, after which keys work.
TUI is unaffected
TUI routes all keys through one central loop and dispatches via engine.handle_context_menu_key() (see src/tui_main/mod.rs:2759). No per-widget focus model — works immediately on menu open.
Suggested fix
GTK-side, when the engine sets context_menu = Some(...), call editor_da.grab_focus() so subsequent keys land on the DA's controller. This is thin event wiring, not new per-backend logic — platform-neutrality-safe.
Three open paths:
- Add
grab_focus() in click.rs after each open_*_context_menu() call.
- Add
grab_focus() once in mod.rs after the click dispatcher returns, conditional on engine.context_menu.is_some().
- (Most invasive) Plumb a
focus_request engine signal that the GTK shell reads after each engine call.
Option 2 is the smallest change.
Related
Problem
When an engine-drawn context menu opens on GTK (editor
…action menu, tab right-click menu, editor right-click menu), keyboard navigation is dead:j/k/Down/Updon't move selection.Enterdoesn't activate.Escapedoesn't dismiss.After clicking inside the menu (anywhere — even a non-clickable separator), all keys start working as expected.
Root cause
src/gtk/mod.rs:5138-5180+has the right key-handler dispatch (Esc/Enter/j/k/Down/Up) routed to engine methods. The dispatch lives on the editorDrawingArea's key event controller, so it only fires when the DA has keyboard focus.Opening a context menu (via right-click or via the
…button click) doesn't currently callgrab_focus()on the editor DA. If focus was elsewhere (e.g. on a sidebar widget, the omnibar, or no widget) when the right-click happened, keys never reach the DA's handler.Clicking inside the menu sends the click to the DA, which incidentally claims focus, after which keys work.
TUI is unaffected
TUI routes all keys through one central loop and dispatches via
engine.handle_context_menu_key()(seesrc/tui_main/mod.rs:2759). No per-widget focus model — works immediately on menu open.Suggested fix
GTK-side, when the engine sets
context_menu = Some(...), calleditor_da.grab_focus()so subsequent keys land on the DA's controller. This is thin event wiring, not new per-backend logic — platform-neutrality-safe.Three open paths:
grab_focus()inclick.rsafter eachopen_*_context_menu()call.grab_focus()once inmod.rsafter the click dispatcher returns, conditional onengine.context_menu.is_some().focus_requestengine signal that the GTK shell reads after each engine call.Option 2 is the smallest change.
Related