Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text selection stops being reported in focus mode #17501

Closed
jcsteh opened this issue Dec 11, 2024 · 4 comments · Fixed by #17503
Closed

Text selection stops being reported in focus mode #17501

jcsteh opened this issue Dec 11, 2024 · 4 comments · Fixed by #17503
Milestone

Comments

@jcsteh
Copy link
Contributor

jcsteh commented Dec 11, 2024

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.

@CyrilleB79
Copy link
Collaborator

Confirmed here!

And thanks @jcsteh to have been able to produce these STR. I have regularly encountered such issue of selection not being reported, but never succeeded in producing reproducible STR.

@jcsteh
Copy link
Contributor Author

jcsteh commented Dec 11, 2024

It's truly infuriating, isn't it? I'm glad I finally figured it out. I assumed it was a Firefox bug until today, but realised when I finally figured out how to reproduce it that it had nothing to do with Firefox.

@Adriani90
Copy link
Collaborator

Could this also be somehow related to #17479?

@jcsteh
Copy link
Contributor Author

jcsteh commented Dec 11, 2024

Highly unlikely. I certainly can't think of a way in which it could be related.

seanbudd pushed a commit that referenced this issue Dec 12, 2024
…xt control from outside a browse mode document. (#17503)

Fixes #17501.

Summary of the issue:
In web browsers, if you focus an editable text control, switch to browse mode, move focus out of the document (e.g. by switching applications) and then switch back to focus mode, changes to the text selection (e.g. shift+arrows) stop being reported.

Description of user facing changes
In web browsers, changes to text selection no longer sometimes fail to be reported in editable text controls.

Description of development approach
EditableTextWithAutoSelectDetection objects initialize auto select detection in event_gainFocus. However, when in browse mode, we deliberately ignore focus events when focus returns from outside the document. This means that event_gainFocus is never called and thus auto select detection is never initialized. The result is that when the user returns to focus mode with an editable text control focused, auto text selection isn't initialized and thus doesn't work at all.

We already handle this initialization in BrowseModeDocumentTreeInterceptor._postGainFocus for some cases. However, we previously weren't calling this when focus returned from outside the document. With this change, we do.

Note that initAutoSelectDetection is the only thing currently performed by _postGainFocus, via the override in the Gecko_ia2 vbuf.
@github-actions github-actions bot added this to the 2025.1 milestone Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants