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 54ba502b9b330e857db0b1c5e67eb5c1709ae642..a1389f8d9ee257b31fb61a7852eef3d7639c2603 100644
--- a/chrome/browser/ui/views/tabs/tab_drag_controller.cc
+++ b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
@@ -382,7 +382,14 @@ void TabDragController::Drag(const gfx::Point& point_in_screen) {
                                          &drag_bounds);
         widget->SetVisibilityChangedAnimationsEnabled(true);
       }
-      RunMoveLoop(GetWindowOffset(point_in_screen));
+      // Always use the start point so the MacViews'

[tapted, 2016/04/06 09:38:51]

This affects all platforms, so we need to say why it's right to use
start_point_in_screen_ in general. Also it's typical in a comment not just to
say something will be wrong, but to say how it's wrong.

I think the gist of this is something like

// Use the start point to initialize the move loop, otherwise the point under
the cursor will be offset by the drag threshold from where the user originally
clicked, which could be entirely off the window.

[themblsha, 2016/04/06 17:54:11]

Thanks, your suggestion is correct and succinct. 

+      // BridgedNativeWidget::RunMoveLoop() could position the window so the
+      // mouse would be directly on top of start_point_in_screen_. Otherwise the
+      // point by which the window is dragged will be wrong.
+      //
+      // The DetachToBrowserTabDragControllerTest.DragAll/0 test on MacViews
+      // will detect the inconsistencies.
+      RunMoveLoop(GetWindowOffset(start_point_in_screen_));
       return;
     }
   }