This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In "Drag-and-drop processing model", it appears that the determination of whether the drop succeeded or failed has been decided before the drop event is fired. Even if the drop event is canceled, this is still considered to be a successful drop. While it doesn't matter from the web page's point-of-view (if the drop handler is smart enough to cancel the event, it's also smart enough to treat the drop as a failure), it does matter for browsers that use feedback to signify drag failure (such as "snap-back" feedback). Should a canceled drop event be treated by the browser as a failure or a success?
Which version of the spec are you reading? This was fixed a while back; if you don't cancel the 'drop' event it is treated as a failed drag for the purposes of "snap-back" feedback. (Canceling events is how you indicate that the script did something and so the UA shouldn't do its default, which in this case is to not drag, i.e. treat it as a failed drag.)
I'm reading the Editor's Draft 30 October 2011 (was at http://dev.w3.org/html5/spec/Overview.html today, but probably won't be tomorrow). I'm not validating the spec against any browsers (WebKit in particular seems to ignore big chunks of it anyway), so this is all in thought-land. Some quotes (with extra detail removed): "If the current drag operation is "none", or if the user ended the drag-and-drop operation by canceling it, or if the current target element is null, then the drag operation failed." ... "Otherwise, the drag operation was as success; run these sub steps:" (including "Let dropped be true." and "fire a DND event named drop") Or, it looks like the success is determined before the drop event is fired, and the success is not changed based upon the cancelation of the drop event. This is probably just an issue with wording. It seems intuitive that canceling the drop event would flag the drop as failed; I was surprised when the spec didn't agree with that intuition. I would move the clause "the drag operation was a success" (and possible "let dropped be true") to a place later in the workflow. Here's my suggestion (I hope the formatting comes out legibly): -------- Otherwise, if the user ended the drag-and-drop operation (e.g. by releasing the mouse button in a mouse-driven drag-and-drop interface), or if the drag event was canceled, then this will be the last iteration. Run the following steps, then stop the drag-and-drop operation: 1. 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 run these substeps: If the current target element is a DOM element, fire a DND event named dragleave at it; otherwise, if it is not null, use platform-specific conventions for drag cancellation. Otherwise, run these substeps: 1. If the current target element is a DOM element, fire a DND event named drop at it; otherwise, use platform-specific conventions for indicating a drop. 2. If the event is canceled, set the current drag operation to the value of the dropEffect attribute of the DragEvent object's dataTransfer object as it stood after the event dispatch finished. Otherwise, the event is not canceled; perform the event's default action, which depends on the exact target as follows: ... 2. If the current drag operation is "none" (no drag operation), then the drag operation failed. Run these substeps: Let dropped be false. Otherwise, the drag operation was a success; run these substeps: Let dropped be true. 3. Fire a DND event named dragend at the source node. 4. Run the appropriate steps from the following list as the default action of the dragend event: ...
The text actually already handles the case you're describing, it's just not very clear. I've tried to clarify the text. Search for where the spec says "If the platform conventions dictate that this be represented to the user (e.g. by animating the dragged selection going back to the source of the drag-and-drop operation), then do so", and notice that the condition for that is that either /dropped/ be false, or that the /current drag operation/ be "none". The latter can happen for several reasons even if /dropped/ is true, in particular, you can set event.dataTransfer.dropEffect to "none" in the "drop" event and cancel it, or, if the user isn't dragging to some text editing region, you can just not handle the event (not cancel it). Does that make sense?
Ah, thank you for the clarification. I was hung up in the earlier section, and didn't notice the clause about drag failure feedback. I see your change ("the drag operation might be a success"), and that helps.