Menu with duplicate accelerators always incorrectly selects the first one

[uxmal]

Describe the bug

A menu with duplicate accelerators, when navigated with the keyboard, will incorrectly select the first one of the duplicates instead of leaving the menu open, to allow the user to type the accelerator again to select the next item, Enter or space to select the current menu item, or Esc to cancel menu naviagation.

To Reproduce

1. Create a window with the following menu:

<Menu>
  <MenuItem Header="_File">
    <MenuItem Header="E_xit" Command="{Binding FileExit}" />
  </MenuItem>
  <MenuItem Header="_View">
    <MenuItem Header="_Duplicate 1" Command="{Binding ViewDuplicate1}"/>
    <MenuItem Header="_Duplicate 2" Command="{Binding ViewDuplicate2}"/>
 </MenuItem>
</Menu>

2. Type Alt+V to bring up the View menu
3. Type D or Alt+D

Result:

The menu is dismissed and the command bound to Duplicate 1 is executed.

Expected:

The menu to remain open, to allow a possible second D to select Duplicate 2

Environment

• OS: reproduced on Windows.
• Avalonia-Version: reproduced on 11.0.4

Additional context

I've attached a zipped VS solution that exhibits the problem.
AvaloniaMenuBug.zip

[StefanKoell]

Hi! This also affects other controls which have a Label with a Target control set. If two labels share the same accelerator, only the first target control is focused instead of cycling through. Also note: there's no visual indicator on the target control that it received the focus. Probably also a bug.

[emmauss]

I don't know of any use case or situation were menu items will not have unique accelerators. In which case would one have duplicate accelerators?

[StefanKoell]

@emmauss then you probably haven't done more complex multi-lingual applications. It's not only affecting menus but also labels in forms. If you have multi-lingual apps where a dedicated team is translating the UI texts, you can't really guarantee that those letters you carefully picked in english are also available in the other language and, of course, you can't really guarantee if those letters are unique in all situations.

besides that, it simply should work as mentioned, at least on windows/Win32/WinForms. it's is a valid scenario and it's also supported that way.

[uxmal]

@emmauss I submit as evidence Microsoft's Visual Studio, a reasonably popular application. It has a user interface whose menus have many menu items, and whose individual menu items can appear in multiple menus. This makes the likelihood of duplicate accelerators higher. In its Edit menu, the s accelerator occurs twice; the Edit menu's Advanced submenu has duplicated L and B accelerators; in the View menu, the v and x accelerators occur twice. There are also various long context menus with duplicated accelerators.

Had Windows' menus worked the way Avalonia's menus work in v11.0.5, users who are restricted to using the keyboard to navigate menus for accessibility would be unable to use Visual Studio's menu system.

This behavior in menus has been present in Windows since at least Windows 95, and is not restricted to menus. E.g. combo boxes, listboxes, and treeviews all support this type of keyboard navigation. If there are multiple visual items that match the letter the user entered, the user interface cycles around all the alternatives until the user confirms with Enter.