DesktopAura: Track windows "owned" via the DesktopWindowTreeHost

ui/views/accessibility/native_view_accessibility.cc

Index: ui/views/accessibility/native_view_accessibility.cc
diff --git a/ui/views/accessibility/native_view_accessibility.cc b/ui/views/accessibility/native_view_accessibility.cc
index 1d5c11a415de6507e384cb15a305141282dbc192..533f51ce5c9c36a297f68c6d40916a557f7cb5b4 100644
--- a/ui/views/accessibility/native_view_accessibility.cc
+++ b/ui/views/accessibility/native_view_accessibility.cc
@@ -255,7 +255,7 @@ void NativeViewAccessibility::PopulateChildWidgetVector(
     return;
 
   std::set<Widget*> child_widgets;
-  Widget::GetAllOwnedWidgets(widget->GetNativeView(), &child_widgets);
+  Widget::GetAllOwnedWidgets(widget->GetNativeView(), &child_widgets, false);

[tapted, 2017/01/25 11:23:03]

I don't think the concept of "ownership" here extends to top-level Widgets. That
is, I think a11y clients would get confused if we started populating a11y info
from another toplevel window in the OS. So, I added the extra argument.

[sky, 2017/01/25 16:41:24]

It's my understanding GetAllOwnedWidget is only called by accessibility. Did you
need to start using it outside of that?

[tapted, 2017/01/27 05:34:55]

Yes - it forms part of http://crbug.com/654151 (added that to BUG=). In the
latest patchset, I've included the change to test_browser_dialog.cc that would
use GetAllOwnedWidget() to give specific context.


There's a bit more in that first BUG= too, i.e. http://crbug.com/683808#c3 says,

"""Note this became an problem for http://crbug.com/681049 because the
dialog-testing harness (TestBrowserDialog) wants to use
Widget::GetAllOwnedWidgets() to detect when a dialog is added to the Chrome
Browser window."""

That is, currently TestBrowserDialog needs a way to (1.) verify that a test case
added a dialog to Chrome, and (2.) close that dialog. GetAllOwnedWidgets() comes
really close to solving this, but didn't work on Windows 10 where
chrome_views_delegate.cc detects Aero and makes a top-level window.


Of course, that's still testing code :/. I didn't realise how much thread I'd be
pulling on when I started down this path.

It does seem that `GetAllOwnedWidgets()` isn't fulfilling its contract right
now, so maybe this is the right approach.

An alternative may be to add some Win- and X11- specific code to
test_browser_dialog.cc that scans through OS window handles and checks for new
Widgets that appear there. 

E.g. 
for (XID xid : DWTHX11PrivateApi::open_windows()) {
 
Widget::GetWidgetForNativeWindow(DestkopWindowTreeHostX11::GetContentWindowForXID(xid));
}

and... something more verbose for Windows.

Not sure how to do this on mus -- probably something involving
views::MusClient::Get()->window_tree_client()->GetRoots() -- which is something
I stole from GetLocalProcessWindowAtPointMus(). I note that appears to be
relying on the duplicate `RegisterNativeWidgetForWindow` entry, I think it could
instead use Widgets::GetAllOwnedWidgets() (I don't think it would need the
changes in this CL, however).

[tapted, 2017/01/30 10:33:04]

/* snip */

In case this pops in your queue first, I've explored this alternative at
https://codereview.chromium.org/2660813002/

   for (auto iter = child_widgets.begin(); iter != child_widgets.end(); ++iter) {
     Widget* child_widget = *iter;
     DCHECK_NE(widget, child_widget);