fix DCHECK in touch drag drop on Windows.

This moves the clearing of the gesture state to before the ole32 drag
drop. Otherwise, the ole32 drag drop nested event loop can trigger
two kGestureScrollBegin events in a row, causing a DCHECK.

Long term, per mustaq@, when the drag-drop controller takes over control
from the gesture recognizer at gesture-long-press, the GR should be
ignoring the "current gesture stream" (from the very first finger going
down until the very last finger leaving the screen).

Bug: 1120809
Change-Id: I792471a2212647282b84d7745c5e7f861b15a28d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2378851
Commit-Queue: David Bienvenu <davidbienvenu@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#802402}

ui/views/widget/desktop_aura/desktop_drag_drop_client_win.cc

@@ -52,6 +52,11 @@ int DesktopDragDropClientWin::StartDragAndDrop(
                        MOUSEEVENTF_RIGHTDOWN | MOUSEEVENTF_ABSOLUTE);
     ui::SendMouseEvent(screen_point, MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE);
     desktop_host_->SetInTouchDrag(true);
+    // Gesture state gets left in a state where you can't start
+    // another drag, unless it's cleaned up. Cleaning it up before starting
+    // drag drop also fixes an issue with getting two kGestureScrollBegin events
+    // in a row. See crbug.com/1120809.
+    source_window->CleanupGestureState();
   }
   base::WeakPtr<DesktopDragDropClientWin> alive(weak_factory_.GetWeakPtr());
 
@@ -69,9 +74,6 @@ int DesktopDragDropClientWin::StartDragAndDrop(
       ui::DragDropTypes::DragOperationToDropEffect(operation), &effect);
   if (alive && source == ui::mojom::DragEventSource::kTouch) {
     desktop_host_->SetInTouchDrag(false);
-    // Gesture state gets left in a state where you can't start
-    // another drag, unless it's cleaned up.
-    source_window->CleanupGestureState();
   }
   drag_source_copy->set_data(nullptr);