This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13203 - Drag-and-drop model should clearly state when and whether a drag is canceled, for Mac-like and X-like drag-cancel effects
Summary: Drag-and-drop model should clearly state when and whether a drag is canceled,...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: a11y, a11y_drag-drop
Depends on:
Blocks:
 
Reported: 2011-07-11 08:34 UTC by contributor
Modified: 2011-11-15 12:56 UTC (History)
10 users (show)

See Also:


Attachments

Description contributor 2011-07-11 08:34:31 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
Multipage: http://www.whatwg.org/C#dndevents
Complete: http://www.whatwg.org/c#dndevents

Comment:
There does not seem to be a way to cancel a drag and drop operation at a point
later than when `dragenter` fires. Often it is useful to be able to cancel it
when the draggable item is dropped, when you know where it is being dropped. I
think it would be great if there was a way to cancel the action, like when you
use the escape key, from script. 

Posted from: 212.181.83.218
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3
Comment 1 Michael[tm] Smith 2011-08-04 05:14:10 UTC
mass-move component to LC1
Comment 2 Jonas 2011-08-04 07:04:21 UTC
Another scenario where it would be useful to be able to abort a D&D action at a later point,
is when you need to inspect the data in the DataTransfer object to determine if you will accept it or not.
Something might accept dropping of URIs, but not all URIs will work. It would then be nice to be able to cancel the d&d action.
Currently, if I am reading the spec right, you can only set data during the `dragstart` event, and you can only read it during the `drop` event.
It's then too early to cancel it during `dragstart` (might start in another application too), and too late to cancel it in `drop`.
Comment 3 Ian 'Hixie' Hickson 2011-08-19 02:59:22 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Why is it too late to cancel it in the drop?
Comment 4 Jonas 2011-08-19 07:01:05 UTC
(In reply to comment #3)
> Status: Did Not Understand Request
> Change Description: no spec change
> Rationale: I don't understand. Why is it too late to cancel it in the drop?

It is too late because there is no way to abort the D&D action at that point, as far as I can tell.
You can only abort in by not accepting drops at all, and at *that* point, you can not read the DataTransfer data in order to make a decision.

The only thing you can do is accept the drop, read the data, then indicate failure some other way.
Comment 5 Gianni Chiappetta 2011-08-19 20:04:31 UTC
I think Jonas' use-case is as simple as he needs to cancel a drag after `dragenter`, based on certain criteria, so it can return to it's origin. I haven't personally tested this, but this seems like a pretty basic (and necessary) behaviour.
Comment 6 Ian 'Hixie' Hickson 2011-08-23 05:13:00 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: It's trivial to cancel the drop in the drop code. Just don't do anything.
Comment 7 Jonas 2011-08-23 08:17:39 UTC
> Rationale: It's trivial to cancel the drop in the drop code. Just don't do
> anything.

Accepting the drop and doing nothing leads to different behavior.

This is different on Windows and OS X, so I suggest checking it out on Chrome (or Safari or FireFox) on OS X, to make it clearer what I mean.

Example here:
http://jsbin.com/oyujuz/3

Chrome 12 on Ubuntu behaves like the aforementioned browsers on OS X, as well.

I hope this clears things up.
Comment 8 Ian 'Hixie' Hickson 2011-09-04 03:29:41 UTC
Ah, yeah, as specced the model totally ignores Mac-like drag cancelation effects.

That shouldn't be hard to fix. Basically, whenever the "current drag operation" is "none" after the "dragend" event, the drag should be considered to be canceled. (Thus to cancel a drag in a 'drop' event you just need to set event.dataTransfer.dropEffect to "none".)
Comment 9 Ian 'Hixie' Hickson 2011-09-23 19:12:59 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: See comment 8.
Comment 10 contributor 2011-09-23 19:14:29 UTC
Checked in as WHATWG revision r6572.
Check-in comment: Explicitly mention when to render drag-cancel feedback.
http://html5.org/tools/web-apps-tracker?from=6571&to=6572