@David, can you take a look at this? We observed this during an a11y review

Shouldn't this be a P1 for M-70 since it completely breaks the chromevox experience in the launcher?

Feel free to re-prioritize. 

Also I can bisect our side of the code if david can't find an issue on his side.

This only hits if you start typing quickly after enabling ChromeVox (I think).

Potential fix is here:
https://chromium-review.googlesource.com/c/chromium/src/+/1159176

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

commit 0de4429aaead184a4468dee14e1d63c1af606053
Author: David Tseng <dtseng@chromium.org>
Date: Thu Aug 02 17:24:03 2018

Remove logic to repost key events when ChromeVox is off

The capture state lives in ash, where ChromeVox sets the state (extension -> browser -> ash).

This state gets delivered (ash -> browser) to the SpokenFeedbackEventRewriterDelegate.

At that point, we should always allow the event to continue onto ChromeVox, and only re-inject if the key is captured.

The previous logic was put into place when this code always sent the delegate all keys.

Bug:  868573 
Change-Id: I6bde8b021d093c52d4450682c4d037a7ef4938a0
Reviewed-on: https://chromium-review.googlesource.com/1159176
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580226}
[modify] https://crrev.com/0de4429aaead184a4468dee14e1d63c1af606053/chrome/browser/chromeos/accessibility/spoken_feedback_event_rewriter_delegate.cc