# HG changeset patch
# User Johann Hofmann <jhofmann@mozilla.com>
# Date 1522947734 -7200
# Node ID 83a2d9c67bb62fa3355ea7cc0541c8c296190a40
# Parent  c6b939712b3174fc37ac69466979893a8d6de9b6
Bug 1446904 - Do not generate drag gestures from synthesized/mouse events while in touch drag mode. r=kats,smaug

Calling GenerateDragGesture at this point should not be necessary, since
eTouchMove events are already handled in the same function. This code
is intermittently triggered through (what I can only call "rogue")
eMouseMove, ePointerDown and ePointerMove events, which is causing hangs
in the native DoDragDrop function further down the stack.

Arguably this shouldn't be triggered by e.g. ePointerDown either, and
I'm unclear on why exactly DoDragDrop is hanging (likely because it is
called again before the user does a drop), but this is a quick fix that
should be suitable for uplift.

MozReview-Commit-ID: A0hBlS85icx

diff --git a/dom/events/EventStateManager.cpp b/dom/events/EventStateManager.cpp
--- a/dom/events/EventStateManager.cpp
+++ b/dom/events/EventStateManager.cpp
@@ -714,17 +714,19 @@ EventStateManager::PreHandleEvent(nsPres
     MOZ_FALLTHROUGH;
   case ePointerMove: {
     // on the Mac, GenerateDragGesture() may not return until the drag
     // has completed and so |aTargetFrame| may have been deleted (moving
     // a bookmark, for example).  If this is the case, however, we know
     // that ClearFrameRefs() has been called and it cleared out
     // |mCurrentTarget|. As a result, we should pass |mCurrentTarget|
     // into UpdateCursor().
-    GenerateDragGesture(aPresContext, mouseEvent);
+    if (!mInTouchDrag) {
+      GenerateDragGesture(aPresContext, mouseEvent);
+    }
     UpdateCursor(aPresContext, aEvent, mCurrentTarget, aStatus);
 
     UpdateLastRefPointOfMouseEvent(mouseEvent);
     if (sIsPointerLocked) {
       ResetPointerToWindowCenterWhilePointerLocked(mouseEvent);
     }
     UpdateLastPointerPosition(mouseEvent);