[GTK4] Fix keyboard navigation in menus

[akurtakov]

Arrow keys did nothing in an open popup or menu bar drop-down:
Shell.gtk_move_focus redirected the traversal to the focus control,
which pulled the focus out of the menu. Move the focus within the
menu's popover instead. Also keep the workbench from restoring the
saved focus while a menu holds it, and restore it once the menu closes.

Left in a submenu closed the whole menu, a menu opened from the
keyboard showed no selection although GTK had focused its first row,
a submenu whose rows Eclipse replaces on SWT.Show lost its focus, and
moving from a native row onto an image row left both rows highlighted.
Hide the submenu before GTK handles Left, select the focused first row
of a menu opened from the keyboard, refocus the first row after
SWT.Show, and clear the other rows when an image row takes the focus.
A tooltip appearing elsewhere cleared the keyboard selection: the
pointer-driven selection sync now leaves it alone while no row is
under the pointer. In a menu with a CHECK item that has an image the
focus got stuck on the first image row: the check indicator claimed
the traversal step without taking the focus, so it is now excluded
from traversal. A submenu with only disabled items trapped the
navigation: GTK put the focus on its scrolled window and kept sending
every key there. Keep the focus on the cascade row instead, let Up and
Down close such a submenu and move on, and let Right leave a menu bar
drop-down from it as from a leaf row.

Assisted-by: Anthropic Claude Code (claude-fable-5-1)

[Copilot]

🟡 Changes recommended

Menu-bar switching can lose focus, skip no disabled entries, and mishandle right-to-left navigation.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Fixes GTK4 keyboard focus and selection behavior for popup menus, menu-bar drop-downs, and submenus.

Changes:

• Routes keyboard traversal through active menu popovers.
• Preserves and restores focus when menus open and close.
• Synchronizes row highlighting and prevents check indicators from capturing traversal.

File summaries

File	Description
Shell.java	Routes focus traversal into GTK4 menus.
MenuItem.java	Corrects custom-row focus and highlighting.
Menu.java	Implements navigation, selection, and focus restoration.
Display.java	Tracks temporarily untargetable menu rows.
GTK.java	Adds GTK direction constants.

Review details

Suppressed comments (2)

bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java:1441

• The deferred restore also runs when this drop-down was hidden because keyboard navigation activated a neighboring menu-bar item. At that point the new menu's focused row is still a descendant of the same parentMenu.handle, so this condition restores the saved control and pulls focus straight back out of the newly opened menu. Exclude focus that is currently inside any menu popover before restoring.

			if (focus == 0 || !GTK.gtk_widget_get_mapped(focus) || parentMenu != null && isDescendant(focus, parentMenu.handle)) shell.restoreFocus();

bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java:1349

• Only the immediately adjacent menu-bar child is tried. If that item is disabled or hidden, gtk_widget_activate does nothing but moveFocus still consumes the arrow key, so keyboard navigation gets stuck instead of advancing to the next usable menu. Walk siblings (with wraparound) until a visible, sensitive item is found, or return without activation after reaching the current item.

	long next = right ? GTK4.gtk_widget_get_next_sibling(item) : GTK4.gtk_widget_get_prev_sibling(item);
	if (next == 0) next = right ? GTK4.gtk_widget_get_first_child(bar) : GTK4.gtk_widget_get_last_child(bar);
	GTK.gtk_widget_activate(next);

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Test Results (linux)

  109 files  ±0    109 suites  ±0   14m 37s ⏱️ -22s
4 632 tests ±0  4 398 ✅ ±0  234 💤 ±0  0 ❌ ±0 
3 470 runs  ±0  3 381 ✅ ±0   89 💤 ±0  0 ❌ ±0 

Results for commit f97a512. ± Comparison against base commit 2d549b1.

♻️ This comment has been updated with latest results.

[Copilot]

🟡 Changes recommended

Closing one menu-bar drop-down can asynchronously pull focus out of a newly opened neighboring menu.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

RTL traversal, popup focus containment, and callback-driven native-handle invalidation remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java:1292

• This only recognizes the LTR “back to parent” key. Menu supports SWT.RIGHT_TO_LEFT and applies an RTL GTK direction, where Right closes a submenu and Left opens it; as written, Right still follows GTK's broken close path and can collapse the whole RTL menu. Choose the closing direction from the menu orientation.

	boolean closing = direction == GTK.GTK_DIR_LEFT && popover != root;

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

Copilot review overview

🟡 Changes recommended

Horizontal submenu navigation does not account for right-to-left menu orientation.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1

Open (1)

• Reverse submenu keyboard directions for RTL menu orientation · New

Resolved since last review (2)

• closeSubmenuFromKeyboard() hides the popover synchronously, which invokes this menu's…
• A failed horizontal traversal is always propagated to the Shell, although only a top-level menu-bar…

[akurtakov]

Merge to get things to usable state so details can be worked on .