Fix overlapping windows in drag test.

Does not currently affect the test, but the minimum size reported by the
toolbar is incorrect (see issue #842239). If the display is small and
the minimum window width grows at all, the target point for the drag
operation ends up still in the first (and focused) window, so the test
fails. This change forces the endpoint of the drag onto the second
window, and raises an error if it cannot do so.

Bug: 898632
Change-Id: If4ee828e3309de247b1940a6b7f8ea98cffd5063
Reviewed-on: https://chromium-review.googlesource.com/c/1372711Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Dana Fried <dfried@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615690}

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

@@ -736,9 +736,16 @@ void DragToSeparateWindowStep2(DetachToBrowserTabDragControllerTest* test,
 
   // Drag to target_tab_strip. This should stop the nested loop from dragging
   // the window.
-  gfx::Point target_point(target_tab_strip->width() / 2,
-                          target_tab_strip->height() / 2);
-  views::View::ConvertPointToScreen(target_tab_strip, &target_point);
+  //
+  // Note: It's possible on small screens for the windows to overlap, so we want
+  // to pick a point squarely within the second tab strip and not in the
+  // starting window.
+  const gfx::Rect old_window_bounds =
+      not_attached_tab_strip->GetWidget()->GetWindowBoundsInScreen();
+  const gfx::Rect target_bounds = target_tab_strip->GetBoundsInScreen();
+  gfx::Point target_point = target_bounds.CenterPoint();
+  target_point.set_x(std::max(target_point.x(), old_window_bounds.right() + 1));
+  ASSERT_TRUE(target_bounds.Contains(target_point));
   ASSERT_TRUE(test->DragInputToAsync(target_point));
 }