Gracefully handle drag cancellation during drag start.

Source/core/page/EventHandler.cpp

Index: Source/core/page/EventHandler.cpp
diff --git a/Source/core/page/EventHandler.cpp b/Source/core/page/EventHandler.cpp
index b2e91147ce635d4132727b17ed825571bf86d053..53555950cc805af090219c79a8b0d10c22ad3fd1 100644
--- a/Source/core/page/EventHandler.cpp
+++ b/Source/core/page/EventHandler.cpp
@@ -3262,8 +3262,12 @@ bool EventHandler::tryStartDrag(const MouseEventWithHitTestResults& event)
     DragController& dragController = m_frame->page()->dragController();
     if (!dragController.populateDragDataTransfer(m_frame, dragState(), m_mouseDownPos))
         return false;
+
+    // If dispatching dragstart brings about a mouse down from deep within its

[dcheng, 2014/08/20 11:16:07]

I might reword this to include the specific circumstance. It's quite unusual
this would occur since normal web content can't synthesize "real" mouse events.
Maybe something like:
"Cancel dragging if another mouse down event arrives during drag start
processing, since the new mouse down will reset a lot of dragging state. This
can happen if the user sets a breakpoint in the dragstart handler and then
clicks on the suspended page."

+    // event handler somehow, the drag operation should also be cancelled. Do
+    // that by checking if m_dragSrc is still set.
     m_mouseDownMayStartDrag = dispatchDragSrcEvent(EventTypeNames::dragstart, m_mouseDown)
-        && !m_frame->selection().isInPasswordField();
+        && !m_frame->selection().isInPasswordField() && dragState().m_dragSrc;
 
     // Invalidate clipboard here against anymore pasteboard writing for security. The drag
     // image can still be changed as we drag, but not the pasteboard data.