Winforms: MenuStrip arrow key navigation goes in the wrong direction

[jeremy-visionaid]

• .NET Core Version:
  At least current master (5.0.100-preview.5.20251.2), but I recall seeing the issue since at least .NET Framework 2.0

• Have you experienced this same bug with .NET Framework?:
  Yes

Problem description:

With a populated MenuStrip, and focus on ToolStripMenuItem that is not top-level, focus shifts in the reverse direction to the arrow key (i.e. pressing the left arrow key causes focus to shift to the right, and pressing the right menu key causes focus to shift to the left). When the focus is on a top-level item, focus shifts in the correct direction.

Expected behavior:
Pressing an arrow key should move in the direction of the arrow

Minimal repro:
The problem is reproducible with the MenuStripAndCheckedListBox winforms test

[jeremy-visionaid]

I think the problem is that ToolStripDropDown uses SystemInformation.RightAlignedMenus property to determine the navigation direction. But, if I understand correctly, this refers to the handedness for a tablet user (i.e. left or right-handed), so the menu alignment is probably not relevant. I think the intention was probably that it should reverse with respect the RightToLeft setting - making the corresponding change fixes the issue for me.

[RussKie]

There was exactly same complaint in https://github.com/gitextensions/gitextensions/issues/5970

[jeremy-visionaid]

@RussKie - Wish I'd spotted that one earlier - would have saved me some time! Thanks for the link!

[weltkante]

But, if I understand correctly, this refers to the handedness for a tablet user (i.e. left or right-handed), so the menu alignment is probably not relevant.

When you are in tablet mode (or ever attached a touch device) menus are supposed to open to the left if you are right handed. The point is that when you use a stylus right handed and menus open to the right, then your right hand would be over the menu and you'd not see any of the options.

It should be a display-only setting, not affecting keyboard input. (Well, maybe the keyboard input for navigating into sub-menus, since submenus are also supposed to open to the opposite side, again to prevent them opening under your hand when doing styles/touch input.)

[jeremy-visionaid]

It should be a display-only setting, not affecting keyboard input. (Well, maybe the keyboard input for navigating into sub-menus, since submenus are also supposed to open to the opposite side, again to prevent them opening under your hand when doing styles/touch input.)

That's a really good point. However, I don't see that changing the handedness in Control Panel affects the display of the menus at all, in any application, including after a reboot (Windows 10 Pro 1909 18363.836). Though the same setting does instantaneously reverse the menu key navigation in a running .NET app. I'd guess the intention is, like you say, that the sub menus _should_ open in a direction dependent on the handedness setting. Since the visual ordering of the top-level menus is dependent on the RightToLeft setting, the navigation would need to respect that too. Unfortunately, I'm not sure I can take this issue any further myself right now since it looks like there's another bug/fault elsewhere too. I'll see if I can repro the faulty menu display on another machine when I can get my hands on one.

[jeremy-visionaid]

So, I've managed to get the handedness to affect the menu display - but only in WPF applications, and it doesn't change the position of the chevron/arrow for sub-menus there. Assuming the WPF behavior I'm seeing is correct, the sub-menu opening direction is only dependent on the RightToLeft setting. So, the issue here looks like it can be fixed by just ignoring the RightAlignedMenus property, since the code to move forward to the next control is RTL aware already. That seems to make the WinForms behavior match WPF for all combinations of RTL and RightAlignedMenus.

[weltkante]

This is weird, the last I checked win32 native menus, WinForms and WPF all behaved identical regarding SystemInformation.RightAlignedMenus. It would be odd if WinUI were to be the one off due to a misunderstanding. This probably needs closer inspection.

[jeremy-visionaid]

@weltkante - I agree. I borrowed an old Windows 7 machine, and the handedness (MenuDropAlignment/RightAlignedMenus) setting takes effect instantaneously in running applications there for at least Win32 native menus. No idea why it doesn't work on my Windows 10 machine, but there does seem to be some bug or configuration issue there.

[jeremy-visionaid]

I got remote access to another Windows 10 machine (also build 18363.836). The behavior was the same - WinForms and Win32 API menu display were unaffected by the MenuDropAlignment/RightAlignedMenus setting.

The arrow key navigation from the pull request seems correct to me with regards to Windows 7 (i.e. the the navigation arrow key you need to press depends on the RTL setting, and the sub-menu is shown on a side that depends on the MenuDropAlignment/RightAlignedMenus setting). As above, that also matches Windows 10 WPF behavior that I'm seeing.

I'd wager that the Win32/WinForms menus displaying on the wrong side on Windows 10 is a separate issue to this, if someone wanted to look into it.

[weltkante]

I can confirm your observations. I don't have a VM ready to check older Win 10 versions, but it sounds like either a regresion in some Win 10 update, or they silently changed the usage of that setting and nobody told the WPF team.

[jeremy-visionaid]

FWIW, with respect to the MenuDropAlignment/RightAlignedMenus affecting the positioning of the drop down menus, I found the following behaviors:

| - | Windows 7 | Windows 10 |
| - | - | - |
| Win32: | Respected | Ignored |
| WinForms | Ignored | Ignored |
| WPF | Respected | Respected |

Given that both Windows versions still have a setting in Control Panel to change this, I think the cases where it's ignored are likely bugs rather than a change in usage.

They keyboard navigation is at least consistent (aside from this problem with WinForms), so I think the fix should still be to ignore the MenuDropAlignment.

[Marie-Shi]

Verified this bug with .Net Core 5.0.100-preview.6.20302.5, it is fixed, now MenuStrip arrow key navigation goes in the correct direction.

[RussKie]

Thank you @Marie-Shi