MacViews: Implement Tab Dragging

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 2799ba073f59cc573b860c6d5872c4b71e39a606..31e7bc6c51eeffd325b7d56a120ed688e45aeb52 100644
--- a/chrome/browser/ui/views/tabs/tab_drag_controller.cc
+++ b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
@@ -390,6 +390,12 @@ void TabDragController::Drag(const gfx::Point& point_in_screen) {
                                          &drag_bounds);
         widget->SetVisibilityChangedAnimationsEnabled(true);
       }
+
+      views::Widget* widget = GetAttachedBrowserWidget();

[sky, 2016/06/16 15:56:12]

As this part is really a separate bug, could you create a patch just for this
and add coverage in existing interactive ui tests?

Also, I think this should be in the else case of the if that starts on 371.

[themblsha, 2016/06/17 14:58:07]

There's already a bug for this:
https://bugs.chromium.org/p/chromium/issues/detail?id=518740#c2

Ok, reverted this code. DetachToBrowserTabDragControllerTest.DragAll /
DetachToBrowserTabDragControllerTest.MacDragsWindowUsingCocoaMoveLoop both
tested for this bug, guess I'll revert their changes as well.

+      gfx::Rect bounds = widget->GetWindowBoundsInScreen();
+      bounds.Offset(point_in_screen.x() - start_point_in_screen_.x(),
+                    point_in_screen.y() - start_point_in_screen_.y());
+      widget->SetBounds(bounds);
       RunMoveLoop(GetWindowOffset(point_in_screen));
       return;
     }