Gracefully handle mismatched drag ended notifications.

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 670605d4c5a1648140a9e21d5867a56398450386..c9fa6caa560deed444e2773afef5bf0aca05198e 100644
--- a/Source/core/page/EventHandler.cpp
+++ b/Source/core/page/EventHandler.cpp
@@ -3206,8 +3206,26 @@ void EventHandler::dragSourceEndedAt(const PlatformMouseEvent& event, DragOperat
     prepareMouseEvent(request, event);
 
     if (dragState().m_dragSrc) {
+        // If an embedder tries to end a drag operation, but the page
+        // has initiated another from other input events received,
+        // we're in a tight corner. While Blink doesn't pretend to
+        // support concurrent drag operations on a page, it should try
+        // to gracefully handle any such overlapping drag operation
+        // attempts, whatever their cause/source.
+        //
+        // Hence, if the drag state here has a source, but not yet
+        // any drag data, this represents a drag operation just
+        // getting under way. The embedder is thus likely signalling
+        // the end of another, earlier drag operation here, which it
+        // is preferable to silently ignore.
+        // (cf. http://crbug.com/445308)
+        if (!dragState().m_dragDataTransfer)

[dcheng, 2015/01/12 22:35:48]

It's not clear to me that this fix/description is correct. I don't see any code
that actually clears m_dragDataTransfer. So it seems a precondition of this
triggering is that this is the first drag on a page.

Then it seems like one of two conditions must be true:
1. In between m_dragSrc being set in EventHandler::handleDrag and
tryStartDrag(), we somehow spin a nested message loop and get a
dragSourceEndedAt() from the browser. I don't see anything that could run a
nested message loop in that short block though.

2. We return after a potential drag source has been selected, and spin the
message loop as the user drags, but the potential drag ends before we ever
exceed the drag hysteresis (and therefore m_dragDataTransfer is still null).

[sof, 2015/01/12 22:47:53]

The testcase sorts under 2, I think.

+            return;
+
         dragState().m_dragDataTransfer->setDestinationOperation(operation);
-        // for now we don't care if event handler cancels default behavior, since there is none
+
+        // For now we don't care if the event handler cancels the default
+        // behavior, as there is none.
         dispatchDragSrcEvent(EventTypeNames::dragend, event);
     }
     clearDragDataTransfer();