[Webkit-unassigned] [Bug 66469] drop event isn't fired unless dragover event is canceled

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66469





--- Comment #10 from Daniel Cheng <dcheng at chromium.org>  2012-10-18 23:04:48 PST ---
(In reply to comment #8)
> Regarding the 'drop' event and the WHATWG specification, I can find no information in the specification that says that the 'drop' event should only be fired if the 'dragover' event is canceled.  The behavior seems out of line with the specification, but I only took a cursory look at the document.  Perhaps I'm wrong about that.
> 

>From http://whatwg.org/html5 about dragover:
If the dragover event is not canceled, run the appropriate step from the following list:

If the current target element is a text field (e.g. textarea, or an input element whose type attribute is in the Text state) or an editing host or editable element, and the drag data store item list has an item with the drag data item type string "text/plain" and the drag data item kind Plain Unicode string
-> Set the current drag operation to either "copy" or "move", as appropriate given the platform conventions.

If the current target element is an element with a dropzone attribute that matches the drag data store and specifies an operation
-> Set the current drag operation to the operation specified by the dropzone attribute of the current target element.

If the current target element is an element with a dropzone attribute that matches the drag data store and does not specify an operation
-> Set the current drag operation to "copy".

Otherwise
-> Reset the current drag operation to "none".

>From later in the same document about the end of the drag and drop operation:
If the current drag operation is "none" (no drag operation), or, if the user ended the drag-and-drop operation by canceling it (e.g. by hitting the Escape key), or if the current target element is null, then the drag operation failed.

It seems pretty clear to me that no drop event should be fired in that case. Note that we're currently incorrectly firing it but I'm planning on fixing that behavior...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.