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
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; |
} |
} |