Temp fix for double tap failing to click focussed item

This is a temp fix for a bug on chromecast screen reader whereby
the item that has a focus ring is not invoked after the user
double taps the screen.

When the touch exploration controller sets an anchor point
explicitly, it issues a click gesture rather than a simulated tap
when the user double clicks the screen.  The click never gets
processed properly by the background page because the
ax tree thinks no window has 'keyboard' focus.  This change
defaults the focus_id field of AXTreeData to be 1 (the root node)
since we only ever have one tree and one window to focus on
anyway.

A long term fix involves fixing other focus issues including
(but not limited to) 1) giving the root window focus via Focus()
call, 2) making sure the root window doesn't lose focus and
3) registering a native widget with the aura::Window or
altering the ax_object_cache logic to not require it when
trying to find the ax tree node corresponding to a window.

Bug: b/111911092
Change-Id: Ide68dbae72288f58711d436db99ef495e5ea9eb0
Reviewed-on: https://chromium-review.googlesource.com/1152897Reviewed-by: Alex Sakhartchouk <alexst@chromium.org>
Commit-Queue: Randy Rossi <rmrossi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578657}

chromecast/browser/ui/aura/accessibility/ax_tree_source_aura.cc

@@ -57,8 +57,24 @@ bool AXTreeSourceAura::GetTreeData(ui::AXTreeData* tree_data) const {
   tree_data->loaded = true;
   tree_data->loading_progress = 1.0;
   AXAuraObjWrapper* focus = AXAuraObjCache::GetInstance()->GetFocus();
+
+  // TODO(b/111911092): AXTreeData::focus_id represents the node within the
+  // tree with 'keyboard focus'.  We have no keyboard focus on chromecast so
+  // this is being left as -1. This prevents getFocus calls from the chromevox
+  // background page from finding any window in focus and interferes with
+  // gesture event processing.  Since we only ever have one top level window
+  // and one ax tree, temporarily returning 1 here to indicate the root node is
+  // always the focused window. A better solution would be to fix the focus
+  // issues on chromecast which relies on a) the root window to be focused via
+  // Focus() and 2) a native widget being registered with the root window so
+  // the above GetFocus call will work.  When this code is re-unified with
+  // chrome, this will need to be a special case for chromecast unless the
+  // better solution described above is implemented.
   if (focus)
     tree_data->focus_id = focus->GetUniqueId().Get();
+  else
+    tree_data->focus_id = 1; // root node
+
   return true;
 }