Avoid creating two resizers for two-finger drag. This CL is trying to avoid creating two separate WindowResizer instances that are now created in both ToplevelWindowEventHandler and TwoFingerDragHandler in the following scenario:

 . Start dragging a window with a touch.
 . Drag a bit, then add a second finger (touching the caption).
 . Continue dragging.
 . Release both fingers.
In this scenario a WindowResizer is first created by ToplevelWindowEventHandler::OnGestureEvent(ET_GESTURE_SCROLL_BEGIN) and then a second instance gets created by TwoFingerDragHandler::ProcessGestureEvent(ET_GESTURE_BEGIN) when a second finger touches down. This scenario is probably an oversight but was not causing too many problems other than occasional window moving jitter. However with the docked windows introduction the DockedWindowLayoutManager currently assumes a single window resizing operation and breaks when FinishDragging is called for the second time.

Additional complication is when this one-two-finger gesture is used to drag a tab out of a browser. In this case The first resizer is created when ToplevelWindowEventHandler::RunMoveLoop is invoked and not as a result of a gesture (not in ToplevelWindowEventHandler::OnGestureEvent). I have added an accessor to the current window resizer to wm::WindowState and use it to determine if a new resizer needs to be created.

I have corrected the state model in TwoFingerDragHandler to always Complete or Revert a drag once it started. This takes care of scenarios when drags start with one or two fingers and get stopped when more fingers are added.

BUG=305730
TEST=interactive_ui_tests --gtest_filter=*TabDragControllerTest*DetachToOwnWindowTwo*/1
TEST=ash_unittests --gtest_filter=*SystemGestureEventFilterTest.TwoFingerDragDelayed*
TEST=ash_unittests --gtest_filter=*SystemGestureEventFilterTest.ThreeFingerGestureStopsDrag*

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=230671

Review URL: https://codereview.chromium.org/28043002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@230798 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 6 insertions, 2 deletions

diff --git a/ash/wm/workspace/workspace_window_resizer.cc b/ash/wm/workspace/workspace_window_resizer.cc
index 7c9394b..61a58a1 100644
--- a/ash/wm/workspace/workspace_window_resizer.cc
+++ b/ash/wm/workspace/workspace_window_resizer.cc
@@ -47,9 +47,12 @@ scoped_ptr<WindowResizer> CreateWindowResizer(
     aura::client::WindowMoveSource source) {
   DCHECK(window);
   wm::WindowState* window_state = wm::GetWindowState(window);
-  // No need to return a resizer when the window cannot get resized.
-  if (!window_state->CanResize() && window_component != HTCAPTION)
+  // No need to return a resizer when the window cannot get resized or when a
+  // resizer already exists for this window.
+  if ((!window_state->CanResize() && window_component != HTCAPTION) ||
+      window_state->window_resizer()) {
     return scoped_ptr<WindowResizer>();
+  }
 
   // TODO(varkha): The chaining of window resizers causes some of the logic
   // to be repeated and the logic flow difficult to control. With some windows
@@ -102,6 +105,7 @@ scoped_ptr<WindowResizer> CreateWindowResizer(
     window_resizer = internal::DockedWindowResizer::Create(
         window_resizer, window, point_in_parent, window_component, source);
   }
+  window_state->set_window_resizer_(window_resizer);
   return make_scoped_ptr<WindowResizer>(window_resizer);
 }