Focusing a menu item after focusing its document container incorrectly switches to browse mode (AKA selecting 1Password items forces browse mode)

[jcsteh]

Steps to reproduce:

1. Open this test case:
   data:text/html,<input onkeydown="if (event.key == 'ArrowDown') { subdoc.focus(); setTimeout(() => menuitem.focus(), 30); }"><div role="document" id="subdoc" tabindex="-1"><div role="menuitem" id="menuitem" tabindex="-1">Test
2. Move to the edit field with the browse mode cursor and press enter to switch to focus mode.
3. Press down arrow.

Actual behavior:

NVDA switches to browse mode and reports the menu item.

Expected behavior:

NVDA should remain in focus mode and report the menu item.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-23817,22dd0118

Windows version:

Windows 10 Version 21H1 (OS Build 19043.1263)

Name and version of other software in use when reproducing the issue:

Firefox Nightly 94.0a1 (2021-09-30) (64-bit)
Chrome Version 96.0.4658.2 (Official Build) canary (32-bit)

Practical Impact

This is problematic when using the 1Password Firefox add-on. I didn't test the Chrome extension, but I'd guess it will happen there too; I believe they're pretty similar. When you're in a text box and you press down arrow to choose a password to auto fill, you get thrown out of focus mode. Navigating the 1Password pop-up is much nicer in focus mode, but having to force focus mode there is annoying. I figured providing a distilled test case would make this easier to debug/fix. :)

Other Info

The focus overlapping cursor check strikes again! Here's what I believe is happening:

1. The document containing the menu item gets focus, so NVDA switches to browse mode.
2. The menu item gets focus.
3. Because the menu item is the first thing in the document, that means the browse mode cursor overlaps with the focus.
4. Thus, NVDA ignores the focus and doesn't switch modes.

It'd be reasonable for this to bounce into browse mode and then back to focus mode because of 1) and then 2). However, it shouldn't stay in browse mode.

I recall there was an attempt to remove the overlapping check a while back, but it got reverted due to problems. I wonder if those problems still apply?
Even if we still need the overlapping check when auto focus focusable elements is enabled, could we avoid the check when that's disabled?
For that matter, given the problems it causes, I wonder whether it's reasonable to consider finally removing auto focus focusable elements now that it's been default off for quite some time without problems?

[jcsteh]

For what it's worth, some conversations with Todd Kloots at Slack suggest the focus overlapping cursor check is causing problems for changes they're considering in Slack as well.