[whatwg] Drag-and-drop feedback

[Ian Hickson]

On Mon, 17 Aug 2009, Jian Li wrote:
>
> In order to download the attachment from an Internet mail application, 
> the user will have to click the attachment link and a "save" dialog will 
> pop up to let the user select the destination folder. This will normally 
> involves multiple clicks. Native application, like Outlook, can let the 
> user drag attachments directly into the destination place, i.e. desktop, 
> which is really convenient.
>
> We propose adding a specific format string to the DataTransfer object: 
> "DownloadURL". The data associated with the "DownloadURL" format should 
> be parsed similar to the "URL" format. When the drag ends in another 
> application, the remote file described in the associated data URL should 
> be downloaded and provided to the target application.

How would this be exposed to other apps? Is it possible in Windows to drop 
something and then have the application that received the drop wait for a 
download (which could take hours) to complete? How does that work?

If we can rely on the download happening before the drag, then we could 
add something to the DataTransfer object to add File objects.


On Fri, 4 Sep 2009, Jens Alfke wrote:
> On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
> > 
> > However, I think the addition of the deferred setData methods could be 
> > added today in a way that is completely backwards compatible with 
> > current implementations and would still be of great benefit. 
> > Specifically, my request for deferring the calling of toString on 
> > non-string objects as such:
> > 
> > event.dataTransfer.setData("something", { toString: function() { 
> > return expensiveFunctionCall(); } });
> > 
> > This would allow me to submit patches to Firefox and WebKit that would 
> > solve the current performance issues which are literally blocking my 
> > ability to switch from "fake" drag and drop to "native" drag and drop. 
> > At the same time, this should still work today in all browsers that 
> > implement setData because the object is coerced into a string 
> > immediately for you, thus not requiring immediate action on their part 
> > to change anything.
> 
> +1. A real drag-n-drop API has to support promised data.

I agree with this in principle, but I think we should wait for DND to be 
properly implemented in current browsers before adding this.


On Tue, 12 Jan 2010, Michael Davidson wrote:
> 
> The table in section 7.9.3 says that the DataTransfer object should be 
> empty for dragenter and dragover events.
> 
> Clearly this is not the case - the example in 7.9.1 shows that, at the 
> very least, the DataTransfer object needs to have a 'types' attribute so 
> that the drag handler can determine if it can accept the drag.

I've tried to clarify what "empty" is supposed to mean here.


> The issue that I'm having is that if the DataTransfer object says that 
> it has Files, I have no way to determine what type those files are. (In 
> this case, I only want to accept image files.) I understand that the 
> DataTransfer shouldn't have the content of the files for security 
> reasons, but it would be helpful if it did contain the file names and/or 
> MIME types.

I could provide a second attribute with the types of the files, would that 
work? I suppose if we did this, we should remove the "Files" fake type. 
That might not be a bad idea in general, it's kind of a hack. I'm not sure 
how I feel about having multiple different ways of representing the data 
in a DataTransfer object... It would give a clean precedent for adding 
other features, though, like promises, which some people have requested.


On Fri, 22 Jan 2010, Daniel Cheng wrote:
>
> Two more questions about implementation details:
> 
> Cut/copy:
> Does it make sense to fire a drag event at all? The spec says that drag
> events should be fired at the source node every 350ms (presumably to allow
> the source node to cancel a drag after it started), but a cut/copy takes
> place "instantaneously".

I've clarified the spec to say that the loop has to happen immediately and 
then only repeat every 350ms if it's still active.


> If drag events should be fired during cut/copy, should the clipboard be 
> restored to its original state if the drag event is cancelled? It would 
> make sense, but might make implementations more complicated.

The idea is for the cut/copy to be done exactly as if it was a drag to a 
hypothetical clipboard window, meaning everything happens in the "drop" 
part, so yes.


> Paste:
> It seems like there is no time a dragleave event would ever fire. A paste
> essentially goes through the drag and drop loop once; the only possible
> transition is for the current target element to go from null to non-null.

The 'dragleave' event can fire during a paste if the drag is canceled.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'