Steps to reproduce:

In Firefox or Edge:

1. Open this test case:
   data:text/html,<textarea autofocus>test</textarea>
2. Ensure the textarea is focused and that you are in focus mode.
3. Press control+home to move to the start of the textarea.
4. Press shift+rightArrow to select "t".
   • Observe: NVDA says: "t selected"
5. Press control+home to clear the selection and move back to the start of the textarea.
6. Switch to browse mode with NVDA+space.
7. Alt+tab out of the browser.
8. Alt+tab back into the browser.
9. Press enter to switch back to focus mode on the textarea.
10. Press shift+rightArrow to select "t".

Actual behavior:

NVDA says nothing at all.

Expected behavior:

NVDA should say: "t selected"

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-34670,def6a444 (2025.1.0.34670)

Windows version:

Windows 11 Version 24H2 (OS Build 26100.2454)

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

Firefox Nightly 135.0a1 (2024-12-10) (64-bit)
Microsoft Edge Version 131.0.2903.86 (Official build) (64-bit)

Other information

This happens whenever focus shifts outside the document while in browse mode, but where focus returns to the same text box inside the document later. For example, it also happens if you focus a text box, switch to browse mode, look around the document, switch to another tab, switch back to the first tab again, move back to the text box and press enter to switch to focus mode. This extended scenario is where this problem becomes really annoying, since it is quite common when writing long form text like emails, comments, etc. where you have to refer to other content.

This bug is not new; it has been driving me wild for years. It's just taken me this long to figure out how to reproduce it reliably.

Here's what I think is happening:

1. When the text box first gains focus, we switch to focus mode.
2. event_gainFocus runs on the text box NVDAObject.
3. Because this is an EditableTextWithAutoSelectDetection object, its event_gainFocus calls initAutoSelectDetection.
4. When you switch to browse mode and then move focus out of the document, the text box loses focus.
5. When you move focus back to the document, you're still in browse mode.
6. The text box gets focus again, but this time, we're in browse mode. That means we do not execute event_gainFocus on the text box.
7. That in turn means that initAutoSelectDetection is not called.
8. When you switch back to focus mode, the text box is already focused, so we don't execute event_gainFocus.
9. The practical upshot is that initAutoSelectDetection is never called for this instance of the object. Thus, auto select detection doesn't work and selection changes are not reported.

It's hard to come up with an elegant fix here. It's definitely not appropriate to call event_gainFocus on the text box when in browse mode because that would result in the focus being spoken like we're in focus mode. We can't simply call event_gainFocus when switching to focus mode if the object already has focus because that could result in a double call to event_gainFocus.

We already have some special case code in browseMode to deal with a similar problem. See the comments containing the text "As we do not call nextHandler which would trigger the vision framework to handle gain focus," in browseMode.py. The easiest (albeit super ugly) fix would be to add a special case for EditableTextWithAutoSelectDetection in these same places.