Fix regression from #7201 where delete would announce the wrong character in Mozilla Gecko edit controls #7496
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…if the word at the caret has changed once _hasCaretMoved_minWordTimeoutMs has elapsed. I.e. 30 ms must elapse before starting to check the word. This fixes a regression introduced by #7201 where deleting characters in Mozilla Gecko editable controls would cause the character being deleted to be spoken rather than the character that followed.
jcsteh
approved these changes
Aug 15, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of the issue:
PR #7201 was created to improve caret tracking by increasing the caret timeout, but also make better use of caret events and word changes to work out exactly when the caret has moved. However, this introduced a regression when pressing delete in Mozilla Gecko edit controls where the character being deleted would be spoken instead of the character following.
As pressing delete does not physically move the caret (rather it just changes the text), we didn't want the increased caret timeout to affect performance of the delete key. Thus that PR keeps checking to see if the word under the caret changes, and when it does it treats that as a caret move.
However, Mozilla Gecko seems to have a bug where when pressing delete, there is a short period of time where the word units correctly change, but the text does not. Thus, NVDA believes the word under the caret changed, before it has fully done so.
An example is:
"This is a test"
Placing the caret on the first character and pressing delete. The word offsets before the delete are 0,5 and the text is "This " (note the space at the end).
After pressing delete, the offsets are 0,4, but the text is "This" (note no space at the end). The offsets are correct, but the text should have been "his " (space at the end).
Before that PR NVDA waited 30 ms before timing out waiting for the caret to move. This was always enough time for Gecko to stabelize and give back the correct information.
Description of how this pull request fixes the issue:
This PR adds a
_hasCaretMoved_minWordTimeoutMsclass variable to editableText.EditableText set to the value 30. _hasCaretMoved now only checks if the word has changed, once this value in ms has elapsed in time. I.e. it again waits for 30 ms at a minimum like older versions of NVDA, but still breaks out earlier than the increased caret timeout if the word has changed.Testing performed:
Deleting characters in the Subject field of a new message in Thunderbird. Arrowing up and down and deleting characters in a new message body. And deleting characters in a multiline edit field in Firefox.
Known issues with pull request:
None.
Change log entry:
None needed.