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

commit 8c109179b324fa818bc4f78f2f0b13de510a4619
Author: David Tseng <dtseng@chromium.org>
Date: Mon Sep 10 18:23:47 2018

Fire focus and blur events before all others in automation

ChromeVox recently began to "stutter" or duplicate output. This occurs most frequently when navigating by headings.

The underlying issue.

ChromeVox requests focus whenever it navigates. This, in turn, triggers actions in Blink. This correctly emits a focus event, along with the correct event from action annotation.

Once it finally arrives in automation, we dispatch the event in js.

In js, we suppress focus events in favor of tracking the focus computation given by AutomationInternalCustomBindings. Unfortunately, if, within the same event bundle, there is an event immediately before the focus event (either generated or not), the event triggers a synthesized focus event, before the actual focus event.

In the end, the incorrect event from value is associated with the synthesized focus event.

This has enormous impact on users as we unpredictably flood users with duplicate feedback. This seems worse on some devices (depending on the event bundle's contents and ordering).

Technical details.
What's happening:

we receive events (in order) like:
1. layout complete (event from page)
2. blur (event from action)
3. focus (event from action)
in the same event bundle.

Before any of these get fired, we unserialize all of the tree data, so the focused node is already updated as far as the tree data is concerned.

After this, we proceed to fire events.

The first one, is the layout complete. This translates into a *focus* event js-side, along with event from page, because that's what the layout complete event had set.

If we honored the actual focus event first, then we would pick up on the right event from action value.

Bug:  881495 
Change-Id: I73b1afc3f1b224ade0cef29a89e00c179438a575
Reviewed-on: https://chromium-review.googlesource.com/1211106
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589987}
[modify] https://crrev.com/8c109179b324fa818bc4f78f2f0b13de510a4619/chrome/renderer/extensions/automation_ax_tree_wrapper.cc
[modify] https://crrev.com/8c109179b324fa818bc4f78f2f0b13de510a4619/chrome/renderer/extensions/automation_internal_custom_bindings.cc
[modify] https://crrev.com/8c109179b324fa818bc4f78f2f0b13de510a4619/chrome/renderer/extensions/automation_internal_custom_bindings.h

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 02cbce7ae5bfca744e419886484728c6eab51330
Author: David Tseng <dtseng@chromium.org>
Date: Thu Sep 13 16:50:57 2018

Merge to m70: Fire focus and blur events before all others in automation

ChromeVox recently began to "stutter" or duplicate output. This occurs most frequently when navigating by headings.

The underlying issue.

ChromeVox requests focus whenever it navigates. This, in turn, triggers actions in Blink. This correctly emits a focus event, along with the correct event from action annotation.

Once it finally arrives in automation, we dispatch the event in js.

In js, we suppress focus events in favor of tracking the focus computation given by AutomationInternalCustomBindings. Unfortunately, if, within the same event bundle, there is an event immediately before the focus event (either generated or not), the event triggers a synthesized focus event, before the actual focus event.

In the end, the incorrect event from value is associated with the synthesized focus event.

This has enormous impact on users as we unpredictably flood users with duplicate feedback. This seems worse on some devices (depending on the event bundle's contents and ordering).

Technical details.
What's happening:

we receive events (in order) like:
1. layout complete (event from page)
2. blur (event from action)
3. focus (event from action)
in the same event bundle.

Before any of these get fired, we unserialize all of the tree data, so the focused node is already updated as far as the tree data is concerned.

After this, we proceed to fire events.

The first one, is the layout complete. This translates into a *focus* event js-side, along with event from page, because that's what the layout complete event had set.

If we honored the actual focus event first, then we would pick up on the right event from action value.

(cherry picked from commit 8c109179b324fa818bc4f78f2f0b13de510a4619)

Bug:  881495 
Change-Id: I73b1afc3f1b224ade0cef29a89e00c179438a575
Reviewed-on: https://chromium-review.googlesource.com/1211106
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: David Tseng <dtseng@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#589987}
Reviewed-on: https://chromium-review.googlesource.com/1224388
Reviewed-by: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#371}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/02cbce7ae5bfca744e419886484728c6eab51330/chrome/renderer/extensions/automation_ax_tree_wrapper.cc
[modify] https://crrev.com/02cbce7ae5bfca744e419886484728c6eab51330/chrome/renderer/extensions/automation_internal_custom_bindings.cc
[modify] https://crrev.com/02cbce7ae5bfca744e419886484728c6eab51330/chrome/renderer/extensions/automation_internal_custom_bindings.h

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

commit 9bdb9118a4958d22a4604566d9e8d8d79ef9e056
Author: David Tseng <dtseng@chromium.org>
Date: Thu Sep 13 21:26:29 2018

Revise panel syncing

As of
https://chromium-review.googlesource.com/c/chromium/src/+/1211106

automation will fire focus and blur events at the beginning of an event "bundle".

Focus will always come first from automation_custom_bindings.js, which tracks the currently focused object and whether it has changed.

In ChromeVox, we can now more predictably use this fact to sync ChromeVox range after the panel is closed. In particular, the next focus event will be either fired upon the content being acted upon by a menu command, or as a target of an incremental search or jump command.

In all cases, first clear the focus by setting focus on the root. This is crucial for clearing the initial focus, which may be at the last position the user navigated. This is not necessarily where we want to be (e.g. when syncing to a heading for the next heading command).


Bug:  881495 
Test: exercise manually: incremental search, control lists (e.g. headings list), and command list.
Change-Id: I63460f3bf7673299f4fa0310859f22d2f60b535b
Reviewed-on: https://chromium-review.googlesource.com/1222348
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591162}
[modify] https://crrev.com/9bdb9118a4958d22a4604566d9e8d8d79ef9e056/chrome/browser/resources/chromeos/chromevox/cvox2/background/panel.js