[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Kinuko Yasuda]

On Fri, Apr 6, 2012 at 12:52 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda <kinuko at chromium.org>wrote:
>
>> A follow up about this proposal:
>>
>> Based on the feedbacks we got on this list we've implemented the
>> following API to do experiments in Chrome:
>>  DataTransferItem.getAsEntry(in EntryCallback callback)
>>
>
> Does this actually need to be async?  The only information you need to
> create the Entry are the filename and the file type (file or directory),
> which the browser can load before performing the drop, so no file I/O is
> needed here.
>

I wanted to make it synchronous, but determining the file type (file or
directory) usually requires blocking file I/O operation, which could spoil
the async nature of this proposal if we perform the blocking stat operation
on every drag-enter event.


> which takes a callback that returns FileEntry or DirectoryEntry if it's
>> for drop event and the item's kind is 'file'.
>> Right now it's prefixed therefore its actual name in Chrome is
>> 'webkitGetAsEntry'.
>> We use kind=='file' in a broader definition here (i.e. a file path which
>> can be either regular file or directory file) and didn't add a specific
>> kind for directories.
>> (Btw we've also implemented DataTransferItem.getAsFile(), so apps can
>> call either getAsFile or webkitGetAsEntry for kind=='file' item)
>>
>
> If getAsEntry is synchronous, a separate getAsFile method isn't needed.
> You can just say transfer.getAsEntry().file(), and reduce the API surface
> area a bit.
>
>  As for lifetime and toURL() issue, which was the biggest concern in the
>> past discussion, we decided not to support toURL/resolveURL on  Entries for
>> drag-and-drop, so that it won't leak reference or expose GC period.  A
>> dragged file can be accessed only while the script has the Entry instance
>> (as well as we do for File object).
>>
>
> I agree with this.  toURL makes some sense within the sandboxed
> filesystem, but it just doesn't for non-sandboxed use.
>
> > We eventually aim to support structured cloning of Entries but it's not
> there yet.
>
> This is sort of a separate issue, but it would be nice to eventually get
> full structured cloning support, with support for File/Entry into
> IndexedDB.  That is, let me store an Entry into IndexedDB, so I can later
> restore it and regain access to the file.  For example, if a user grants my
> music player web app access to his MP3 collection, I can store the
> resulting Entry in IndexedDB (or History), and the user can load my web app
> later and start playing music, without having to re-open the directory
> every time.  This needs further thought around user expectations of how
> long access grants last, but hopefully it can be worked out eventually.
>
> (We don't need to go into this here; just mentioning it again while it's
> on my mind, so people can be thinking about it.)
>

Supporting structured cloning sounds like the right direction to me too.


> As for <input type="file"> support I am thinking about adding "AsEntries"
>> attribute (so that we do not need to do the automatic recursive
>> files/directories retrieval when the attribute is specified) and "entries"
>> field, but haven't done anything yet.  (Open to further suggestions)
>>
>
> This sounds right, too.  This would make File access from <input>
> obsolete.  (File would still avoid at least one asynchronous call for
> non-recursive use cases, though, so people will still use it.)
>

Thanks for showing your support, I hope we can uniformly support Entry both
in <input> and native drag-and-drop.


>  I hope we can get valuable user feedbacks (as well as from yours) based
>> on the implementation.
>>
>
> This sounds good.  Once we've played around with this for a while, we can
> start thinking about how to safely expose write access.
>

Yes!


> --
> Glenn Maynard
>
>