Linux Aura: Use managed tab dragging when possible (Reland)

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

Index: chrome/browser/ui/views/tabs/tab_drag_controller.cc
diff --git a/chrome/browser/ui/views/tabs/tab_drag_controller.cc b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
index 605f476d6ac5a190f73ebede31ccb3a6e99f0e4d..cf3b3ebb17fab446cb635ace7fc30d81deea0d02 100644
--- a/chrome/browser/ui/views/tabs/tab_drag_controller.cc
+++ b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
@@ -379,6 +379,7 @@ void TabDragController::Drag(const gfx::Point& point_in_screen) {
     }
     started_drag_ = true;
     Attach(source_tabstrip_, gfx::Point());
+    gfx::Point drag_point_in_screen = point_in_screen;
     if (static_cast<int>(drag_data_.size()) ==
         GetModel(source_tabstrip_)->count()) {
       if (was_source_maximized_ || was_source_fullscreen_) {
@@ -403,6 +404,7 @@ void TabDragController::Drag(const gfx::Point& point_in_screen) {
                                          &drag_bounds);
         widget->SetVisibilityChangedAnimationsEnabled(true);
       } else {
+#if !defined(OS_LINUX) || defined(OS_CHROMEOS)
         // The user has to move the mouse some amount of pixels before the drag
         // starts. Offset the window by this amount so that the relative offset
         // of the initial location is consistent. See crbug.com/518740
@@ -411,8 +413,14 @@ void TabDragController::Drag(const gfx::Point& point_in_screen) {
         bounds.Offset(point_in_screen.x() - start_point_in_screen_.x(),
                       point_in_screen.y() - start_point_in_screen_.y());
         widget->SetBounds(bounds);
+#else
+        // Linux does not need the window offset hack above because all drag
+        // implementations move windows relative to a passed-in cursor position
+        // instead of the implicit current cursor position.
+        drag_point_in_screen = start_point_in_screen_;

[sky, 2016/10/12 15:58:33]

I'm confused by this. If you use the original starting location, then don't you
miss the kMinimumDragDistance?

Also, in this context 'hack' is rather negative and the above code isn't a hack.
It's there to ensure specific behavior.

[Tom (Use chromium acct), 2016/10/12 18:08:27]

No, because I removed the widget->SetBounds above.

The reason I needed to do this is the SetBounds eventually results in a request
to move the window sent to the window manager.  The WM would then snap the
window to within the screen bounds, and we would then request the WM move the
window in RunMoveLoop with a stale starting point.
Sorry, removed.  I said that because that code was added to overcome a
limitation only on Windows platforms.

+#endif
       }
-      RunMoveLoop(GetWindowOffset(point_in_screen));
+      RunMoveLoop(GetWindowOffset(drag_point_in_screen));
       return;
     }
   }