mus: Use the new drag API to implement tab dragging in chrome.

chrome/browser/ui/views/tabs/window_finder_mus.cc

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/ui/views/tabs/window_finder_mus.h"
+
+#include "ui/aura/window.h"
+#include "ui/views/mus/native_widget_mus.h"
+#include "ui/views/mus/window_manager_connection.h"
+
+WindowFinderMus::WindowFinderMus() {}
+
+WindowFinderMus::~WindowFinderMus() {}
+
+gfx::NativeWindow WindowFinderMus::GetLocalProcessWindowAtPoint(
+    const gfx::Point& screen_point,
+    const std::set<gfx::NativeWindow>& ignore) {
+  std::set<mus::Window*> mus_windows =
+      views::WindowManagerConnection::Get()->GetRoots();
+  // TODO(erg): Needs to deal with stacking order here.

[Elliot Glaysher, 2016/06/29 22:41:57]

This is where I'm a little bit lost. While mus::Window has methods to reorder
itself, there doesn't appear to be a way to sort mus::Windows by screen
ordering.

[sky, 2016/06/30 00:18:31]

The other TODO you should add is that this only handles windows created by
chrome. We'll have to decide what the right path is going forward for this, by
which I mean I'm not quite sure yet. I see two options:
. have a way for chrome to see all windows.
. add an api to mus for querying what this code needs to do.
Have to ponder what the right thing is.

[Elliot Glaysher, 2016/06/30 19:48:25]

I don't believe that's an issue.

WindowFinder::GetLocalProcessWindowAtPoint() has one caller, and that's in the
tab dragging code, looking specifically for chrome windows of the current
process that you can drag a tab into (and ignoring the windows |ignore| which
are the window being dragged).

[sky, 2016/06/30 23:23:54]

It would be nice if WindowFinder::GetLocalProcessWindowAtPoint had some docs,
eh? The expectation is that GetLocalProcessWindowAtPoint() only returns a local
window if that window is not obscured by another window. TO do otherwise means
chrome will try to attach to a window that isn't necessarily visible.

[Elliot Glaysher, 2016/07/01 00:09:58]

Added what I've learned by reverse engineering to the toplevel, previously
undocumented, window_finder.h.

+
+  // For every mus window, look at the associated aura window and see if we're
+  // in that.
+  for (mus::Window* mus : mus_windows) {
+    views::Widget* widget = views::NativeWidgetMus::GetWidgetForWindow(mus);
+    if (widget && widget->GetWindowBoundsInScreen().Contains(screen_point)) {
+      aura::Window* content_window = widget->GetNativeWindow();
+
+      // If we were instructed to ignore this window, ignore it.
+      if (ContainsKey(ignore, content_window))
+        continue;
+
+      return content_window;
+    }
+  }
+
+  return nullptr;
+}