Chromium-based browsers: buggy text navigation in multiline edit fields #9786
Comments
codeofdusk
added a commit
to codeofdusk/nvda
that referenced
this issue
Jun 21, 2019
Closed
|
I can confirm this. It's been a problem for a while now, although I can't remember how long. It happens in all versions of Chrome and Edge with alpha versions of NVDA as well as stable. I apologize if this shows up twice. I replied via email but it doesn't look like it worked. |
|
This was fixed by the reverting of #9773 and can be closed. |
feerrenrut
pushed a commit
that referenced
this issue
Jul 24, 2019
## Summary of the issue: In text fields, when moving the caret with caret movement commands, such as the arrows, NVDA relies on bookmarks to find out whether the caret has moved. In short: 1. You press left arrow 2. NVDA creates a bookmark of the current caret position 3. NVDA executes left arrow 4. For up to the caret movement timeout, NVDA tries to find out whether the caret has moved by creating new bookmarks and comparing them against the old. However, for UIA, this comparison fails, as creating a bookmark at the end of a range and then removing one character from the end of the range results in a new bookmark that is equal to the former. ## Description of how this fixes the issue: This PR introduces a different approach based on #9773. In first instance, this code caused #9786 to occur (i.e. editors in Chrome reporting the wrong caret position). Compared to #9773, flow is now as follows: - In a loop in EditableText._hasCaretMoved, NVDA processes pedning events - If there is a focus event pending, the loop is exited - NVDA tries to find out whether the caret position has changed by creating a textInfo at the caret position - new code: only when this succeeds, NVDA checks for pending caret and textChange events. If the object that contains the caret has caretMovementDetectionUsesEvents set to False, it still ignores the caret events. This is what we do in IA2Web objects. ## Testing performed: - Tested that deleted characters/words are again reported in UIA controls, such as MS Word - Tested Notepad, Wordpad, Word Without UIA, Thunderbird, LibreOffice, start menu edit field, legacy command consoles and Skype Electron. Made sure that the caret was still correctly reported in all of them when moving with arrow keys or deleting. ## Known issues with pull request: We can't set the caretMovementDetectionUsesEvents attribute to True on editableText.EditableText and then override it in other places, such as IA2Web. This is because EditableText precedes the IA2Web class as well as other classes in the mro Setting it on EditableText directly therefore makes it impossible for other classes to override the attribute. I solved this by making it a magic property on EditableText that first tries to call super before returning the default. Fixes #9928 Follow up of PR #9773
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce:
Actual behavior:
Wrong lines are spoken when arrowing up and down, and wrong words are spoken when moving by word. Also, often, character positions are reported wrong, making editing a dangerous task with unpredictable results.
Expected behavior:
None of the above, editing should be normal.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
Observed in alpha-17750,27694a31. Does not occur in alpha-17743,5883af56.
Windows version:
19h1.
Name and version of other software in use when reproducing the issue:
Chromium-based browsers.
Other information about your system:
Other questions
Does the issue still occur after restarting your PC?
Yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
See above, a regression from a checkin of #9773. CC @codeofdusk and @michaelDCurran.
The text was updated successfully, but these errors were encountered: