Both issues are down at the level of webview accessibility.

For 1, I'm seeing multiple focus events when you first enter or leave the webview. The webview fires focus on the first focusable item (the password text field) and then whatever else you're supposed to land on (e.g. the next link).


2. even if we explicitly set focus on the text field, it appears input focus isn't set correctly at the webview level.

Both issues need deeper investigation.

As an additional note, the webview also sets a title of sign into your Chromebook (during OOBE). This gets picked up as an accessible name and is unfortunately also the label for the heading 1. This causes ChromeVox to read out the name multiple times. The heading itself appears to split the text into two lines
"sign into your"
"Chromebook"

So, when navigating by lines (Search+down), we also split this up.

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

commit 20d6d96d1e472287cb4270b1d6c8b48973994fcd
Author: dtseng <dtseng@chromium.org>
Date: Fri Nov 04 19:31:18 2016

Fix reset and focus issues in OOBE

- if an extension is toggled off then on, and re-requests the desktop automation tree, it might receive tree data for a child tree before the child tree's accessibility data is reset via
chrome.automation.enableFrame.
This results in the client extension tree having an embeddedObject node with one child with role unknown.
Fix this by always resetting a child tree root that has unknown role

- work around webview focus issues by explicitly always checking the ancestors we've crossed into and always focusing first embeddedObject nodes. This should be removed once webview handles propagating upwards focus from descendants correctly.

BUG= 660390 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2470413005
Cr-Commit-Position: refs/heads/master@{#429978}

[modify] https://crrev.com/20d6d96d1e472287cb4270b1d6c8b48973994fcd/chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js
[modify] https://crrev.com/20d6d96d1e472287cb4270b1d6c8b48973994fcd/chrome/renderer/resources/extensions/automation_custom_bindings.js

I can still see issues as explained in #0 on 56.0.2919.0 build

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

commit 3d0aa6a69b15dadb70ecbff3428e55589966bbbc
Author: dtseng <dtseng@chromium.org>
Date: Thu Nov 17 01:41:05 2016

Try focusing embeddedObject first unconditionally

We attempt, on each navigation, to focus an unfocused embeddedObject for which we are entering (i.e. the embeddedObject is an ancestor).

During this process, we might have exited early if we encountered a focused range.

Ensure we always check for embeddedObject's to focus.

TEST=navigate in OOBE sign in screen via tab/Search+left/right. Ensure we're getting focus inside of the webview e.g. type into the text field, navigate outside to the shutdown button, navigate back into the webview, type more into the email text field and verify stuff works.
BUG= 660390 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2509093002
Cr-Commit-Position: refs/heads/master@{#432684}

[modify] https://crrev.com/3d0aa6a69b15dadb70ecbff3428e55589966bbbc/chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js

Fixed as much as we can for now. These are all secondary symtoms of webview's poor programmatic focus practices (e.g. setting focus to things inside the webview doesn't actualy cause the webview to get focus itself).