Fixes tab dragging out of a window with maximzied bounds

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 53e78b4301c955701ee2323282382206eb33c2e3..b3461fe41e39185779b0fb1a6d93db952778738e 100644
--- a/chrome/browser/ui/views/tabs/tab_drag_controller.cc
+++ b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
@@ -77,6 +77,12 @@ const int kHorizontalMoveThreshold = 16;  // Pixels.
 // close enough to trigger moving.
 const int kStackedDistance = 36;
 
+// A dragged window is forced to be a bit smaller than maximized bounds during a
+// drag. This prevents the dragged browser widget from getting maximized at
+// creation and makes it easier to drag tabs out of a restored window that had
+// maximized size.
+const int kMaximizedWindowInset = 10;  // Pixels.

[sky, 2015/06/06 17:59:30]

Again, is this really pixels?

[varkha, 2015/06/06 20:13:17]

I thought so. This is same units as mouse travel, window bounds, etc. Are there
cases when this is something else?

+
 #if defined(USE_ASH)
 void SetWindowPositionManaged(gfx::NativeWindow window, bool value) {
   ash::wm::GetWindowState(window)->set_window_position_managed(value);
@@ -1640,6 +1646,20 @@ gfx::Rect TabDragController::CalculateDraggedBrowserBounds(
   gfx::Point center(0, source->height() / 2);
   views::View::ConvertPointToWidget(source, &center);
   gfx::Rect new_bounds(source->GetWidget()->GetRestoredBounds());
+
+  gfx::Rect work_area =
+      screen_->GetDisplayNearestPoint(last_point_in_screen_).work_area();

[sky, 2015/06/05 19:24:27]

Shouldn't this be an else condition of maximized? Also, make sure you try this
on windows.

[varkha, 2015/06/05 19:48:48]

I thinks this should be complimentary rather than an else on IsMaximized.
Consider the case when a window is manually resized to work_area bounds and then
maximized. Its restore bounds will be equal to work_area and unless we adjust
the restore bounds the tab will be undraggable. I have tested this theory and
indeed the bug remains in that corner case if I move the logic under else. Both
this corner case and the one described in the bug are fixed if I leave the logic
where it is now.
I have added a unit test that tests this corner case on Windows (where the only
new behavior is that the window will be maximized after drag). Would you trust
that?

+  if (new_bounds.size().width() >= work_area.size().width() &&
+      new_bounds.size().height() >= work_area.size().height()) {
+    new_bounds = work_area;
+    new_bounds.Inset(kMaximizedWindowInset, kMaximizedWindowInset,
+                     kMaximizedWindowInset, kMaximizedWindowInset);
+    // Behave as if the |source| was maximized at the start of a drag since this
+    // is consistent with a browser window creation logic in case of windows
+    // that are as large as the |work_area|.
+    was_source_maximized_ = true;
+  }
+
   if (source->GetWidget()->IsMaximized()) {
     // If the restore bounds is really small, we don't want to honor it
     // (dragging a really small window looks wrong), instead make sure the new