Gracefully handle mismatched drag ended notifications.

Source/core/page/EventHandler.cpp

 /*
  * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Apple Inc. All rights reserved.
  * Copyright (C) 2006 Alexey Proskuryakov (ap@webkit.org)
  * Copyright (C) 2012 Digia Plc. and/or its subsidiary(-ies)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
@@ skipping 3188 matching lines @@
     }
 }
 
 void EventHandler::dragSourceEndedAt(const PlatformMouseEvent& event, DragOperation operation)
 {
     // Send a hit test request so that RenderLayer gets a chance to update the :hover and :active pseudoclasses.
     HitTestRequest request(HitTestRequest::Release);
     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();
     dragState().m_dragSrc = nullptr;
     // In case the drag was ended due to an escape key press we need to ensure
     // that consecutive mousemove events don't reinitiate the drag and drop.
     m_mouseDownMayStartDrag = false;
 }
 
 void EventHandler::updateDragStateAfterEditDragIfNeeded(Element* rootEditableElement)
@@ skipping 668 matching lines @@
 unsigned EventHandler::accessKeyModifiers()
 {
 #if OS(MACOSX)
     return PlatformEvent::CtrlKey | PlatformEvent::AltKey;
 #else
     return PlatformEvent::AltKey;
 #endif
 }
 
 } // namespace blink