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

NVDA unable to track cursor in the GMail message composer when using Chrome #6424

ssawczyn opened this issue Oct 2, 2016 · 3 comments


Copy link

@ssawczyn ssawczyn commented Oct 2, 2016

When composing a new Email or replying to an Email within GMail using Chrome, NVDA does not properly track the cursor. Specifically, NVDA does not read the character on which the cursor is located. To replicate this:

  1. Using Chrome open GMail in standard view.
  2. Compose a new message.
  3. Type some text in the message area.
  4. Attempt to edit text.
Copy link

@jcsteh jcsteh commented Oct 5, 2016

@jcsteh jcsteh added the GoogleWork label Oct 5, 2016
Copy link

@feerrenrut feerrenrut commented Oct 6, 2016

Assuming we understand the issue, and Jamie has described it correctly. We think this issue is improving with updates to Chrome, while annoying this seems to be reasonably usable in Chrome canary. This would be a large chunk of uncertain work to work around in nvda. Applying a P3 label. Any questions or clarifications welcome.

Copy link

@feerrenrut feerrenrut commented Jan 6, 2017

A quick approach to reducing the frequency that this occurs could be to increase the time out used to wait for the caret to move.

jcsteh added a commit that referenced this issue Jun 7, 2017
…figurable. Incubates #7201 (issue #6424).
jcsteh added a commit that referenced this issue Jun 21, 2017
jcsteh added a commit that referenced this issue Jun 22, 2017
jcsteh added a commit that referenced this issue Jun 26, 2017
… Incubates #7201 (issue #6424). Fixes #7323.
@jcsteh jcsteh closed this in #7201 Jul 10, 2017
@nvaccessAuto nvaccessAuto added this to the 2017.3 milestone Jul 10, 2017
jcsteh added a commit that referenced this issue Jul 10, 2017
…figurable (PR #7201, issue #6424)

- 30 ms was chosen to ensure maximum responsiveness, but this just isn't enough in the wild; e.g. in complex web editors (particularly in Chrome) or when connecting to remote terminals with connection latency.
- This is configurable via config.conf["editableText"]["caretMoveTimeout"]. It is not exposed in the GUI, as this should only be changed by advanced users. The value is in ms, not seconds, as that's a better unit for this purpose. However, the function continues to use seconds for its arguments for backwards compatibility.
- Previously, _hasCaretMoved slept at the end of the loop but didn't check for caret movement again. This meant that it could return False even if the caret did actually move during the last sleep. Now, the timeout check happens after the caret movement check, ensuring the correct result.
- _hasCaretMoved now works with ms rather than seconds to avoid floating point precision errors. These precision errors could result in an extraneous additional retry.
- Added some debug logging to help diagnose caret tracking problems in future.
- When pressing the delete key, we often can't detect this by comparing bookmarks. Therefore, when pressing delete, compare the word at the caret (in addition to bookmarks) to detect movement.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants
You can’t perform that action at this time.