Menubar Focus

Syntec

When using tab on the keyboard to cycle through controls if you tab to menubar from a control with allow focus, the control never loses focus to the menu bar. I am not sure this is intended or not. I would expect the menu bar to pull focus.

Garry

This is expected behaviour. Menu bars aren’t normally included in the regular Tab order.

On Windows and Linux, you should be able to activate the menu bar using Alt, F10, or Alt plus the underlined menu letter. On macOS, the standard shortcut is Control-F2 (or Fn-Control-F2).

Setting AllowFocus makes the Canvas a normal tab stop, but it doesn’t make the menu bar the next tab stop. If the Canvas is the only focusable control, pressing Tab may therefore leave focus on it.

Which operating system are you using, and do the appropriate menu-bar shortcuts above work? If they don’t, that would be a bug.

Syntec

Garry

I will try to explain this better.

I am on Windows 11, and the menubar does respond to tab inputs.

The basic setup is, I have two custom canvas buttons, button1 does nothing, button2 disables button1. For testing purposes button1 and button2 update a label to say "Button 1 Focused" / "Button 2 Focused" under FocusReceived event, and update the label to "" under FocusLost Event.

Steps.

Run Program
Press Tab --> Result is File on menubar becomes highlighted
Press Tab --> Button1 receives focus and has a focus ring, label updates to "Button 1 Focused"
Press Tab --> Button 2 receives focus and has a focus ring. label updates to "Button 2 Focused"
Press Tab --> File on menubar becomes highlighted, Button 2 loses focus ring and updates label to ""
Press Return --> File menu opens, but Button 2 receives focus updates label to "Button 2 Focused" but has no focus ring. Pressing return with File menu open fires Button 2 Pressed Event.

In order to use the file menu with the keyboard you must press tab again (even though the menu is open to re highlight file then navigate with arrow keys, its like Button 2 stole the focus. If you just press tab on the first run before button 2 ever had focus, file menu opens and you can navigate the menu as expected.

Garry

Thanks. Your second explanation made the problem clear, and I was able to reproduce it. This is a bug, so my original reply was incorrect.

When the menu opened, the runtime refreshed its contents for the MenuOpening event by recreating the native menu-item controls. On Windows, that removed the currently focused menu item, causing focus to revert to the previously focused control — Button 2 in your example — even though the File menu remained visibly open. Return was consequently being delivered to Button 2 instead of the menu.

I’ve fixed this so menu items are updated in place and keyboard focus remains inside the opened menu. The fix also preserves dynamic MenuOpening changes such as updating, checking, or adding menu items.

Tracked here: https://feedback.objo.dev/bug/1126

Thanks for the detailed reproduction steps.