MenuBar: Left/Right arrow navigation gets stuck around submenus

This content was largely generated by AI. AI makes mistakes.

Describe the bug

MenuBar Left/Right arrow navigation between top-level menus becomes inconsistent when submenus are involved:

• Left on a submenu-owning item: Left can switch to the previous top-level menu when an ordinary menu item is highlighted, but stops working when the highlighted item owns a submenu, such as View > Zoom.
• Right from inside a submenu: After entering a submenu and highlighting a leaf item, Right does not continue to the next top-level menu.

This behavior was reported in modern Windows 11 Notepad. This filing captures the reported behavior; it has not yet been independently reproduced in a version-pinned minimal WinUI app.

Why is this important?

Keyboard users should be able to navigate a menu bar consistently without switching to the mouse or backing out and reopening menus. Whether an item happens to contain a submenu should not prevent navigation in a direction that would otherwise switch top-level menus.

This affects keyboard accessibility and efficiency in desktop and enterprise apps that rely on menus. It also differs from familiar Win32 menu navigation.

Steps to reproduce the bug

The reported Notepad navigation sequences are:

Left-arrow case

1. Open modern Notepad on Windows 11.
2. Open the View menu.
3. Highlight an ordinary item without a submenu and press Left. Observe that navigation can move to the previous top-level menu.
4. Reopen View and highlight Zoom, which owns a submenu. Keep the highlighted item on Zoom in the parent menu, rather than moving into its submenu.
5. Press Left and compare the result with step 3. The same inconsistency is reported when hovering the submenu-owning item.

Right-arrow case

1. Open View and highlight Zoom.
2. Press Right to enter the Zoom submenu.
3. Highlight a leaf item, such as Zoom in, that does not own another submenu.
4. Press Right again to continue to the next top-level menu.

Actual behavior

• Left does not switch to the previous top-level menu when the highlighted parent-menu item owns a submenu.
• Right does not switch to the next top-level menu from a leaf item inside a submenu.

Expected behavior

Match the corresponding Win32-style menu navigation:

• From an item in a top-level menu's flyout, Left should switch to the previous top-level menu even when that item owns a submenu.
• Right should enter a submenu when the highlighted item owns one. From a leaf item inside a submenu, Right should continue to the next top-level menu, using the menu bar's normal wraparound behavior where applicable.
• Preserve normal submenu exit behavior: Left from inside a submenu should close that submenu and return to its parent item.

Screenshots

The public report below includes a video demonstrating both arrow-key navigation problems.

NuGet package version

Not provided in the original report. Exact Windows App SDK / WinUI package and app versions still need to be captured.

Windows version

Windows 11. Exact version and build were not provided.

Additional context

Public report: https://blog.yuo.be/2026/09/10/the-terrible-menu-bar-in-the-windows-11-notepad/

This issue is specifically about arrow-key navigation around submenus. Mouse press-drag-release behavior, animations, F10, and access-key presentation are outside its scope.

No source file or test entry point is named. First reproduce the reported Left/Right sequences in a version-pinned WinUI app, then trace menu-bar and submenu keyboard handling; done means matching the stated Win32-style transitions while preserving Left-based submenu exit behavior.