[whatwg] Drag-and-drop feedback

[Jian Li]

On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson <ian at hixie.ch> wrote:

> 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.
>
>
We cannot do the download before the drag because the drop target might not
accept the drag or the user might press ESC to cancel the drag-and-drop. We
do not want to do any unnecessary download before we know for sure that the
user really wants it.

It could be possible that the target application could be blocked for long
time if we do not provide the drag-and-drop information in a nice way. On
Windows, we could provide a download file in two ways: file path or file
stream. For the former way, a file has to be downloaded first before the
target application can consume it and thus the target application will be
blocked until the download completes. For the latter way, we use the file
stream to transfer the data between the source application and the target
application and thus the target application will not be blocked if it uses a
background thread (this is what Windows Shell does). On MacOSX, a file
stream is also used for such purpose.

However, we need to provide more metadata about the download when we call
DataTransfer.setData("DownloadURL", ...). This is because on Windows we need
to know about the file name and size when the drag is initiated. We can wait
till we get the headers to extract the file name and size but this is
blocking. Even more, if the http chunk mode is used, we cannot get the size
from the headers. On MacOSX, we need to provide the mime type and file name.
Could we consider adding mime type, file name and size information into the
data value parameter of setData method? For example,
    dataTransfer.setData("DownloadURL", "text/plain:1000:
http://example.com/download.txt");


>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100125/82c64251/attachment-0002.htm>