Removes grab input window and extra grab and ungrab in X11WholeScreenMoveLoop

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 54f836d1eb6b0a2a5b1774deb2f9bb9baf0b500b..ee2c1bdbdaa429b0cb4452f1e8d0c40ff8f4111a 100644
--- a/chrome/browser/ui/views/tabs/tab_drag_controller.cc
+++ b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
@@ -1179,6 +1179,8 @@ void TabDragController::DetachIntoNewBrowserAndRunMoveLoop(
   browser->window()->Show();
   dragged_widget->RemoveObserver(&updater);
   dragged_widget->SetVisibilityChangedAnimationsEnabled(true);
+  // Set capture after the newly created browser widget is visible.
+  attached_tabstrip_->GetWidget()->SetCapture(attached_tabstrip_);

[sky, 2014/05/27 13:27:04]

Couple of questions. Why is this needed here since Attach should set capture?
Since this seems X11 specific, can it be moved to
DesktopWindowTreeHostX11::RunMoveLoop?

[varkha, 2014/05/28 19:11:46]

I had this comment here before, but it is higher up the review chain:
This makes sure that capture is really where we think it is after calling
Attach(). Attach() would normally set capture on attached widget but with Aura
fails to do so because of IsVisible() check in Window::SetCapture(). This was
wrong before but worked because of additional capture in X11WholeScreenMoveLoop.
Simplifying X11WholeScreenMoveLoop exposed this.
It worked on other Aura platforms because NativeWidgetAura::RunMoveLoop calls
SetCapture.
There is already SetCapture in X11DesktopWindowMoveClient::RunMoveLoop which is
called from DesktopWindowTreeHostX11::RunMoveLoop so this should not be
necessary and I reverted this part of the change.

   // Activate may trigger a focus loss, destroying us.
   {
     base::WeakPtr<TabDragController> ref(weak_factory_.GetWeakPtr());