The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c7892d1149066d68ea1c0cf861670f6ce1f300d

commit 0c7892d1149066d68ea1c0cf861670f6ce1f300d
Author: David Tseng <dtseng@chromium.org>
Date: Tue Dec 05 19:49:11 2017

Fix degraded typing feedback

- EditableTextBase's state transitions that detect insertions are unreliable:
1. when typing quickly, Chrome can and does combine events. type the keys 1, 2,
3 quickly and you might get value/text changes for "1", "12", and "123"; or you
might get value changes for "1", "123". The latter is really bad and triggers
the insertion (with length > 1) state erroniously.
2. the source of the insertion is unclear. It might have been from a paste, programmatic splicing.
3. It is impossible to reconstruct what part of the text actually got
inserted. Trivial example: 'aaa', 'aaaaaaaa'. Unknown whether the entire value was replaced, or just a substring.

In this change, we will turn off insertion announcements, which were being
triggered in many undesirable code paths.

Instead, we will:
- listen to clipboard events for cut, copy, paste (and
remove the previous copy command)
- fixes the regression introduced by splitting
text field into several subroles. Set selection wasn't working.

Test: type a lot with various typing echo settings and cut/copy/paste.

Bug: 791157
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ida442aa0656c1d66e489c6064f8959ccb7177b46
Reviewed-on: https://chromium-review.googlesource.com/804535
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521793}
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/chromevox/background/keymaps/next_keymap.json
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/chromevox/injected/event_watcher_test.unitjs
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/common/editable_text_base.js
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/common/editable_text_test.unitjs
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/cvox2/background/command_handler.js
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/cvox2/background/desktop_automation_handler.js
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/browser/resources/chromeos/chromevox/cvox2/background/editing_test.extjs
[modify] https://crrev.com/0c7892d1149066d68ea1c0cf861670f6ce1f300d/chrome/renderer/resources/extensions/automation/automation_node.js

Please verify; thanks!

 Issue 791688  has been merged into this issue.

Version 65.0.3286.0 (Official Build) canary (64-bit)(
Firmware Version Google_Samus.6300.174.0

This fix should be in this version, but I did not notice a change while testing.

Fix was actually for 791688.

+aleventhal as FYI. Likely the same problem for all screen readers.

Given:
"line1 abc
 line2 123"

with selection immediately before "line2 123", Ctrl+Left moves selection to immediately before "abc".

From simply observing the states:
- selection
- line text

there is no way to tell if the state change is line movement or word movement.

Assuming we had 
- Ctrl+Left => "move by word"

we could make that logic work to read "abc"

The bug neferenced also happens in monorail, when reading the contents of a new issue. To repro, press Search+A+I, tab to the issue description box, arrow down to step 1, and press right arrow to the end of the line, and then navigate past the end of the line. Notice that the second line, in its entirety, is uttered. The same happens when moving backwards. This is in latest canary 5 build.

Thanks for the additional data point. Same underlying issue applies -- no way to distinguish between whether you moved from one line to another via line movement or character movement. Relying upon key events won't generalize to things like braille display input, touch gestures, and other non-keyboard driven forms of input.

This will require we plumb through edit commands from Blink.

 Issue 833252  has been merged into this issue.

FYI 833252 is not the same issue. One is a change in the underlying text (e.g. via typing) and this issue is a change in the selection (but the text is the same) between states in the text field.

This one is a bit less annoying/unexpected but also requires more semantics out of Blink. It is blocked on work there, so I'm lowering priority since it's not going to happen in this milestone or likely the next).