Keep track of accessibility focus across windows.

Keep track of accessibility focus across windows.

Previously we never kept track of accessibility focus; when a
web element or view got focus we'd fire an accessibility focus
event and leave it up to the client to keep track.

This worked fine when focus is only changing within a single
window. However, this led to lots of subtle bugs and race
conditions across windows, for example:

1. If a View in a non-activatable window tried to get focus,
we'd fire a focus event even though the View didn't actually
get keyboard focus.

2. If the active element in a non-focused frame changed,
we'd fire a focus event even though that frame's window
did not have focus.

3. Tabbing into or out of a cross-process iframe or
<webview> element could fire a focus event on both
the outer and inner frame, another race condition.

To solve this, we this change makes the following
changes:

1. Within a single accessibility tree, the focused node
is now part of the tree data, rather than a state flag on
a node. That guarantees only one node within a tree
can be focused at once. This affects both the web
accessibility tree and the views accessibility tree.

2. Whenever we get an accessibility focus event, we
start at the root and figure out what node has focus,
globally. Then we only fire the accessibility focus event
on that new node if focus has changed.

As an example, suppose we open a Chrome app that
embeds a <webview> that loads the google.com homepage,
which focuses the input element. Initially the app window
itself does not have focus, so we don't fire any focus events.

Later the app window gets activated. We now follow the focus
chain to the <webview> element and to the focused input
element, and fire a focus event on the input element
directly.

BUG=581910
Committed: https://crrev.com/965ba000de4c91156005af7e23235574f8c2cc93
Cr-Commit-Position: refs/heads/master@{#376339}

[dmazzoni, 2016-01-28 00:06:17]

Description was changed from

==========
Not for review yet. Focus in AXTreeData.

BUG=
==========

to

==========
Keep track of accessibility focus accurately.

BUG=581910
==========

[dmazzoni, 2016-01-28 00:06:18]

dmazzoni@chromium.org changed reviewers:
+ dtseng@chromium.org

[dmazzoni, 2016-01-28 00:34:07]

Description was changed from

==========
Keep track of accessibility focus accurately.

BUG=581910
==========

to

==========
Keep track of accessibility focus across windows.

Previously we never kept track of accessibility focus; when a
web element or view got focus we'd fire an accessibility focus
event and leave it up to the client to keep track.

This worked fine when focus is only changing within a single
window. However, this led to lots of subtle bugs and race
conditions across windows, for example:

1. If a View in a non-activatable window tried to get focus,
we'd fire a focus event even though the View didn't actually
get keyboard focus.

2. If the active element in a non-focused frame changed,
we'd fire a focus event even though that frame's window
did not have focus.

3. Tabbing into or out of a cross-process iframe or
<webview> element could fire a focus event on both
the outer and inner frame, another race condition.

To solve this, we this change makes the following
changes:

1. Within a single accessibility tree, the focused node
is now part of the tree data, rather than a state flag on
a node. That guarantees only one node within a tree
can be focused at once. This affects both the web
accessibility tree and the views accessibility tree.

2. Whenever we get an accessibility focus event, we
start at the root and figure out what node has focus,
globally. Then we only fire the accessibility focus event
on that new node if focus has changed.

As an example, suppose we open a Chrome app that
embeds a <webview> that loads the google.com homepage,
which focuses the input element. Initially the app window
itself does not have focus, so we don't fire any focus events.

Later the app window gets activated. We now follow the focus
chain to the <webview> element and to the focused input
element, and fire a focus event on the input element
directly.

BUG=581910
==========

[dmazzoni, 2016-01-28 00:34:41]

Ready for an initial look!

[David Tseng, 2016-01-28 02:00:56]

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/extensio...
File chrome/browser/extensions/api/automation/automation_apitest.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/automation/automation_apitest.cc:168:
IN_PROC_BROWSER_TEST_F(AutomationApiTest, DesktopFocusWeb) {
Should this work on all platforms?

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js
(right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js:488:
// If the new mode is Classic, return now so we don't announce
Maybe add something to queue the next utterance?

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js:492: 
nit: extra line

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/ui/aura/...
File chrome/browser/ui/aura/accessibility/automation_manager_aura.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/ui/aura/...
chrome/browser/ui/aura/accessibility/automation_manager_aura.cc:139:
aura_obj->Serialize(&temp1);
nit: Unused/remove.

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
File chrome/common/extensions/api/automation.idl (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
chrome/common/extensions/api/automation.idl:620: // null if the none of the
nodes in any loaded trees have focus.
nit: if none of

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
File chrome/common/extensions/chrome_extension_messages.h (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
chrome/common/extensions/chrome_extension_messages.h:83:
IPC_STRUCT_TRAITS_MEMBER(focus_id)
nit: alphabetized?

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
File chrome/test/data/extensions/api_test/automation/tests/desktop/focus_web.js
(right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
chrome/test/data/extensions/api_test/automation/tests/desktop/focus_web.js:32:
event.target.parent.focus();
Why is this call made?

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
File
chrome/test/data/extensions/api_test/automation/tests/desktop/initial_focus.js
(right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
chrome/test/data/extensions/api_test/automation/tests/desktop/initial_focus.js:7:
chrome.test.succeed();
This looks wrong.

https://codereview.chromium.org/1589623002/diff/40001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/1589623002/diff/40001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_cocoa.mm:2037:
manager->SetFocus(*browserAccessibility_);
Btw, how does someone clear focus and is browserAccessibility_ guaranteed to be
non-null?

https://codereview.chromium.org/1589623002/diff/40001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_manager.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_manager.cc:298: }
Are there clients on other platforms that may need the initial focus event?

https://codereview.chromium.org/1589623002/diff/40001/ui/views/accessibility/...
File ui/views/accessibility/ax_aura_obj_cache.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/ui/views/accessibility/...
ui/views/accessibility/ax_aura_obj_cache.cc:123: //if (focus_client_)
nit: remove

https://codereview.chromium.org/1589623002/diff/40001/ui/views/accessibility/...
ui/views/accessibility/ax_aura_obj_cache.cc:144: focused_widget =
Widget::GetWidgetForNativeView(focused_window);
Do we want to break once we find a non-null widget?

[dmazzoni, 2016-01-30 00:02:41]

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/extensio...
File chrome/browser/extensions/api/automation/automation_apitest.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/automation/automation_apitest.cc:168:
IN_PROC_BROWSER_TEST_F(AutomationApiTest, DesktopFocusWeb) {
On 2016/01/28 02:00:56, David Tseng wrote:
> Should this work on all platforms?

Yes, this should work on all Aura platforms.

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js
(right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js:488:
// If the new mode is Classic, return now so we don't announce

On 2016/01/28 02:00:56, David Tseng wrote:
> Maybe add something to queue the next utterance?

For Classic? Did you have something specific in mind? I'm not sure how to do
this and I'd rather not spend time on improving Classic.

Right now the experience is that switching to Next says "Next", followed by
whatever has focus, and switching to Classic just says "Classic" and doesn't
currently announce anything.

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/background.js:492: 
On 2016/01/28 02:00:56, David Tseng wrote:
> nit: extra line

Done.

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/ui/aura/...
File chrome/browser/ui/aura/accessibility/automation_manager_aura.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/browser/ui/aura/...
chrome/browser/ui/aura/accessibility/automation_manager_aura.cc:139:
aura_obj->Serialize(&temp1);
On 2016/01/28 02:00:56, David Tseng wrote:
> nit: Unused/remove.

Done.

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
File chrome/common/extensions/api/automation.idl (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
chrome/common/extensions/api/automation.idl:620: // null if the none of the
nodes in any loaded trees have focus.
On 2016/01/28 02:00:56, David Tseng wrote:
> nit: if none of

Done.

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
File chrome/common/extensions/chrome_extension_messages.h (right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/common/extension...
chrome/common/extensions/chrome_extension_messages.h:83:
IPC_STRUCT_TRAITS_MEMBER(focus_id)
On 2016/01/28 02:00:56, David Tseng wrote:
> nit: alphabetized?

This matches the order they're defined (and documented) in ax_tree_data.h, I
think that makes more sense than alphabetizing them since when adding or
removing a field that makes it easier to compare the two side-by-side.

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
File chrome/test/data/extensions/api_test/automation/tests/desktop/focus_web.js
(right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
chrome/test/data/extensions/api_test/automation/tests/desktop/focus_web.js:32:
event.target.parent.focus();
On 2016/01/28 02:00:56, David Tseng wrote:
> Why is this call made?

This focuses the webview that contains the second window's document. If you
don't do this, focus could be anywhere inside the second window, like that
window's location bar.

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
File
chrome/test/data/extensions/api_test/automation/tests/desktop/initial_focus.js
(right):

https://codereview.chromium.org/1589623002/diff/40001/chrome/test/data/extens...
chrome/test/data/extensions/api_test/automation/tests/desktop/initial_focus.js:7:
chrome.test.succeed();
On 2016/01/28 02:00:56, David Tseng wrote:
> This looks wrong.

Wow! Yeah, not much of a test. Luckily that was an accidental change towards the
end, it really does pass without it. :)

https://codereview.chromium.org/1589623002/diff/40001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/1589623002/diff/40001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_cocoa.mm:2037:
manager->SetFocus(*browserAccessibility_);
On 2016/01/28 02:00:56, David Tseng wrote:
> Btw, how does someone clear focus and is browserAccessibility_ guaranteed to
be
> non-null?

Yes, browserAccessibility_ is non-null because BrowserAccessibilityCocoa
outlives the object it wraps.

What should clear focus mean, now that we're thinking about focus more globally?
Is there a specific use-case?

https://codereview.chromium.org/1589623002/diff/40001/ui/views/accessibility/...
File ui/views/accessibility/ax_aura_obj_cache.cc (right):

https://codereview.chromium.org/1589623002/diff/40001/ui/views/accessibility/...
ui/views/accessibility/ax_aura_obj_cache.cc:123: //if (focus_client_)
On 2016/01/28 02:00:56, David Tseng wrote:
> nit: remove

Done.

https://codereview.chromium.org/1589623002/diff/40001/ui/views/accessibility/...
ui/views/accessibility/ax_aura_obj_cache.cc:144: focused_widget =
Widget::GetWidgetForNativeView(focused_window);
On 2016/01/28 02:00:56, David Tseng wrote:
> Do we want to break once we find a non-null widget?

Not necessary since this is at the bottom of the while loop, right?

[David Tseng, 2016-01-30 00:19:19]

lgtm

[dmazzoni, 2016-02-12 23:12:33]

dmazzoni@chromium.org changed reviewers:
+ dcheng@chromium.org, jam@chromium.org

[dmazzoni, 2016-02-12 23:12:34]

+jam for:
  chrome/browser/apps/guest_view/web_view_browsertest.cc
  chrome/browser/extensions/api/automation/automation_apitest.cc
  content/browser/renderer_host/render_widget_host_view_mac.mm

+dcheng for:
  chrome/common/extensions/chrome_extension_messages.h
  content/common/accessibility_messages.h
  third_party/WebKit/Source/core/dom/AXObjectCache.h
  third_party/WebKit/Source/web/WebDocument.cpp
  third_party/WebKit/Source/web/resources/calendarPicker.js
  third_party/WebKit/public/web/WebDocument.h  

Ready for another look. This ended up being a tricky
change but I think well worth it.

[jam, 2016-02-12 23:33:18]

lgtm

[dcheng, 2016-02-13 02:29:31]

https://codereview.chromium.org/1589623002/diff/300001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp
(right):

https://codereview.chromium.org/1589623002/diff/300001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp:161: if
(!page->focusController().focusedOrMainFrame()->isLocalFrame())
Why focusedOrMainFrame()? Is it because we have to pick something even if no
frame is focused?

[dmazzoni, 2016-02-16 18:54:54]

https://codereview.chromium.org/1589623002/diff/300001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp
(right):

https://codereview.chromium.org/1589623002/diff/300001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp:161: if
(!page->focusController().focusedOrMainFrame()->isLocalFrame())
On 2016/02/13 02:29:31, dcheng wrote:
> Why focusedOrMainFrame()? Is it because we have to pick something even if no
> frame is focused?

Ah, looks like we can just call focusedFrame() - that will either return a
LocalFrame or nullptr if it's remote, which is what we want. If the focused
frame is remote we want to return null so the AXObjectCache for that remote
frame can handle it.

Looking at the TODO in the source of FocusController::focusedFrame(), do you
think it'd be helpful to add a synonym like focusedFrameIfLocal() or
focusedFrameOrNullIfRemote() so that it's clear that this is OOPIF-aware? Up to
you.

[David Tseng, 2016-02-17 23:55:56]

lgtm

https://codereview.chromium.org/1589623002/diff/340001/chrome/browser/resourc...
File
chrome/browser/resources/chromeos/chromevox/cvox2/background/desktop_automation_handler.js
(right):

https://codereview.chromium.org/1589623002/diff/340001/chrome/browser/resourc...
chrome/browser/resources/chromeos/chromevox/cvox2/background/desktop_automation_handler.js:52:

No need for the load complete logic above now?

https://codereview.chromium.org/1589623002/diff/340001/chrome/renderer/extens...
File chrome/renderer/extensions/automation_internal_custom_bindings.cc (right):

https://codereview.chromium.org/1589623002/diff/340001/chrome/renderer/extens...
chrome/renderer/extensions/automation_internal_custom_bindings.cc:811:
TreeCache* focused_node_treecache = nullptr;
nit: focused_tree_cache

[dcheng, 2016-02-18 19:36:20]

On 2016/02/16 at 18:54:54, dmazzoni wrote:
>
https://codereview.chromium.org/1589623002/diff/300001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp
(right):
> 
>
https://codereview.chromium.org/1589623002/diff/300001/third_party/WebKit/Sou...
> third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.cpp:161: if
(!page->focusController().focusedOrMainFrame()->isLocalFrame())
> On 2016/02/13 02:29:31, dcheng wrote:
> > Why focusedOrMainFrame()? Is it because we have to pick something even if no
> > frame is focused?
> 
> Ah, looks like we can just call focusedFrame() - that will either return a
LocalFrame or nullptr if it's remote, which is what we want. If the focused
frame is remote we want to return null so the AXObjectCache for that remote
frame can handle it.
> 
> Looking at the TODO in the source of FocusController::focusedFrame(), do you
think it'd be helpful to add a synonym like focusedFrameIfLocal() or
focusedFrameOrNullIfRemote() so that it's clear that this is OOPIF-aware? Up to
you.

Hm, we intentionally wrote it this way: the idea is anyone asking for the
focused frame should have already been directed to the right renderer process,
so focusedFrame() should only return a LocalFrame*. Thus should naming it
focusedFrame() is shorter / more obvious.

Two questions before I l-g-t-m:
1) Did you find this naming surprising/confusing? I'm hoping not to make the
names significantly more verbose but if it's hindering understanding, that's
something to consider.
2) I guess accessibility is different: it asks all the renderers for their AX
trees, which causes each process to check for the focused frame, regardless of
whether or not that process has focus, right?

[dmazzoni, 2016-02-18 19:53:37]

> > On 2016/02/13 02:29:31, dcheng wrote:
> Two questions before I l-g-t-m:
> 1) Did you find this naming surprising/confusing? I'm hoping not to make the
> names significantly more verbose but if it's hindering understanding, that's
> something to consider.

Since site isolation hasn't launched yet I'm not sure whether every API that
returns
a LocalFrame is supposed to be used anymore. So it's not confusing, but it is
ambiguous as to whether it returns null if the focused frame is remote, or
asserts
in that case.

> 2) I guess accessibility is different: it asks all the renderers for their AX
> trees, which causes each process to check for the focused frame, regardless of
> whether or not that process has focus, right?

Very shortly I intend to simplify this even more by having exactly one
AXObjectCache per frame. Then we won't even care about whether each frame has
focus or not - we just keep track of the active element within each frame, and
in the browser process keep track of what frame has focus. But in the meantime
we need to figure out if focus is in any local frame or not, since the
AXObjectCache spans all local frames.

Considering that's the plan and I may not need to call focusedFrame() anymore,
perhaps it's not worth renaming.

[dcheng, 2016-02-18 19:54:57]

lgtm

[dmazzoni, 2016-02-18 23:56:37]

https://codereview.chromium.org/1589623002/diff/340001/chrome/browser/resourc...
File
chrome/browser/resources/chromeos/chromevox/cvox2/background/desktop_automation_handler.js
(right):

https://codereview.chromium.org/1589623002/diff/340001/chrome/browser/resourc...
chrome/browser/resources/chromeos/chromevox/cvox2/background/desktop_automation_handler.js:52:

On 2016/02/17 23:55:56, David Tseng wrote:
> No need for the load complete logic above now?

Agreed, let's try removing it in a follow-up.

https://codereview.chromium.org/1589623002/diff/340001/chrome/renderer/extens...
File chrome/renderer/extensions/automation_internal_custom_bindings.cc (right):

https://codereview.chromium.org/1589623002/diff/340001/chrome/renderer/extens...
chrome/renderer/extensions/automation_internal_custom_bindings.cc:811:
TreeCache* focused_node_treecache = nullptr;
On 2016/02/17 23:55:56, David Tseng wrote:
> nit: focused_tree_cache

Done.

[dmazzoni, 2016-02-18 23:58:53]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2016-02-18 23:58:54]

The patchset sent to the CQ was uploaded after l-g-t-m from jam@chromium.org,
dtseng@chromium.org, dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/1589623002/#ps400001
(title: "Final suggestions")

[commit-bot: I haz the power, 2016-02-19 00:07:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1589623002/400001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1589623002/400001

[commit-bot: I haz the power, 2016-02-19 01:43:33]

Description was changed from

==========
Keep track of accessibility focus across windows.

Previously we never kept track of accessibility focus; when a
web element or view got focus we'd fire an accessibility focus
event and leave it up to the client to keep track.

This worked fine when focus is only changing within a single
window. However, this led to lots of subtle bugs and race
conditions across windows, for example:

1. If a View in a non-activatable window tried to get focus,
we'd fire a focus event even though the View didn't actually
get keyboard focus.

2. If the active element in a non-focused frame changed,
we'd fire a focus event even though that frame's window
did not have focus.

3. Tabbing into or out of a cross-process iframe or
<webview> element could fire a focus event on both
the outer and inner frame, another race condition.

To solve this, we this change makes the following
changes:

1. Within a single accessibility tree, the focused node
is now part of the tree data, rather than a state flag on
a node. That guarantees only one node within a tree
can be focused at once. This affects both the web
accessibility tree and the views accessibility tree.

2. Whenever we get an accessibility focus event, we
start at the root and figure out what node has focus,
globally. Then we only fire the accessibility focus event
on that new node if focus has changed.

As an example, suppose we open a Chrome app that
embeds a <webview> that loads the google.com homepage,
which focuses the input element. Initially the app window
itself does not have focus, so we don't fire any focus events.

Later the app window gets activated. We now follow the focus
chain to the <webview> element and to the focused input
element, and fire a focus event on the input element
directly.

BUG=581910
==========

to

==========
Keep track of accessibility focus across windows.

Previously we never kept track of accessibility focus; when a
web element or view got focus we'd fire an accessibility focus
event and leave it up to the client to keep track.

This worked fine when focus is only changing within a single
window. However, this led to lots of subtle bugs and race
conditions across windows, for example:

1. If a View in a non-activatable window tried to get focus,
we'd fire a focus event even though the View didn't actually
get keyboard focus.

2. If the active element in a non-focused frame changed,
we'd fire a focus event even though that frame's window
did not have focus.

3. Tabbing into or out of a cross-process iframe or
<webview> element could fire a focus event on both
the outer and inner frame, another race condition.

To solve this, we this change makes the following
changes:

1. Within a single accessibility tree, the focused node
is now part of the tree data, rather than a state flag on
a node. That guarantees only one node within a tree
can be focused at once. This affects both the web
accessibility tree and the views accessibility tree.

2. Whenever we get an accessibility focus event, we
start at the root and figure out what node has focus,
globally. Then we only fire the accessibility focus event
on that new node if focus has changed.

As an example, suppose we open a Chrome app that
embeds a <webview> that loads the google.com homepage,
which focuses the input element. Initially the app window
itself does not have focus, so we don't fire any focus events.

Later the app window gets activated. We now follow the focus
chain to the <webview> element and to the focused input
element, and fire a focus event on the input element
directly.

BUG=581910
==========

[commit-bot: I haz the power, 2016-02-19 01:43:35]

Committed patchset #21 (id:400001)

[commit-bot: I haz the power, 2016-02-19 01:44:33]

Description was changed from

==========
Keep track of accessibility focus across windows.

Previously we never kept track of accessibility focus; when a
web element or view got focus we'd fire an accessibility focus
event and leave it up to the client to keep track.

This worked fine when focus is only changing within a single
window. However, this led to lots of subtle bugs and race
conditions across windows, for example:

1. If a View in a non-activatable window tried to get focus,
we'd fire a focus event even though the View didn't actually
get keyboard focus.

2. If the active element in a non-focused frame changed,
we'd fire a focus event even though that frame's window
did not have focus.

3. Tabbing into or out of a cross-process iframe or
<webview> element could fire a focus event on both
the outer and inner frame, another race condition.

To solve this, we this change makes the following
changes:

1. Within a single accessibility tree, the focused node
is now part of the tree data, rather than a state flag on
a node. That guarantees only one node within a tree
can be focused at once. This affects both the web
accessibility tree and the views accessibility tree.

2. Whenever we get an accessibility focus event, we
start at the root and figure out what node has focus,
globally. Then we only fire the accessibility focus event
on that new node if focus has changed.

As an example, suppose we open a Chrome app that
embeds a <webview> that loads the google.com homepage,
which focuses the input element. Initially the app window
itself does not have focus, so we don't fire any focus events.

Later the app window gets activated. We now follow the focus
chain to the <webview> element and to the focused input
element, and fire a focus event on the input element
directly.

BUG=581910
==========

to

==========
Keep track of accessibility focus across windows.

Previously we never kept track of accessibility focus; when a
web element or view got focus we'd fire an accessibility focus
event and leave it up to the client to keep track.

This worked fine when focus is only changing within a single
window. However, this led to lots of subtle bugs and race
conditions across windows, for example:

1. If a View in a non-activatable window tried to get focus,
we'd fire a focus event even though the View didn't actually
get keyboard focus.

2. If the active element in a non-focused frame changed,
we'd fire a focus event even though that frame's window
did not have focus.

3. Tabbing into or out of a cross-process iframe or
<webview> element could fire a focus event on both
the outer and inner frame, another race condition.

To solve this, we this change makes the following
changes:

1. Within a single accessibility tree, the focused node
is now part of the tree data, rather than a state flag on
a node. That guarantees only one node within a tree
can be focused at once. This affects both the web
accessibility tree and the views accessibility tree.

2. Whenever we get an accessibility focus event, we
start at the root and figure out what node has focus,
globally. Then we only fire the accessibility focus event
on that new node if focus has changed.

As an example, suppose we open a Chrome app that
embeds a <webview> that loads the google.com homepage,
which focuses the input element. Initially the app window
itself does not have focus, so we don't fire any focus events.

Later the app window gets activated. We now follow the focus
chain to the <webview> element and to the focused input
element, and fire a focus event on the input element
directly.

BUG=581910

Committed: https://crrev.com/965ba000de4c91156005af7e23235574f8c2cc93
Cr-Commit-Position: refs/heads/master@{#376339}
==========

[commit-bot: I haz the power, 2016-02-19 01:44:36]

Patchset 21 (id:??) landed as
https://crrev.com/965ba000de4c91156005af7e23235574f8c2cc93
Cr-Commit-Position: refs/heads/master@{#376339}