-
-
Notifications
You must be signed in to change notification settings - Fork 655
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
Comments
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. |
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. |
Could this also be somehow related to #17479? |
Highly unlikely. I certainly can't think of a way in which it could be related. |
…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.
Steps to reproduce:
In Firefox or Edge:
data:text/html,<textarea autofocus>test</textarea>
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:
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.
The text was updated successfully, but these errors were encountered: