Re: [whatwg] Forms: <input type=file> and directory tree picking

On Fri, 2 Aug 2013, Jonathan Watt wrote:
>
> I'm working on Mozilla's implementation of <input type=file> to allow 
> the user to pick a directory. The idea would be that the files in that 
> directory and its subdirectories would be added to the 
> HTMLInputElement.files FileList.

This seems to be dangerous in that it makes it really easy for the user to 
select a single item that expands into tens of thousands if not millions 
of files on a remote disk, which then all have to be synchronously 
enumerated to get the count so that code can then itself enumerate through 
the entire list.


> The advantage of avoiding the need for the 'directory' attribute would 
> be that directory picking would work for existing content with <input 
> type=file multiple> without needing to be changed. One disadvantage 
> would be that existing content may depend on the file names in the 
> FileList being unique.

I would have liked the file names to still be unique, by prefixing the 
names with the relevant parts of the subpaths (that is, if I select 
foo.txt and bar/ which contains another foo.txt, .files would contain 
"foo.txt" and "bar/foo.txt"), but I think that ship sailed (and now the 
spec explicitly requires otherwise).


> We would change the File interface to add a 'path' property, which would 
> be the path (without the file name) of the file relative to the 
> directory that was picked.

That might work.


> Currently authors can use HTMLInputElement.click() to open a system file 
> picker. To give content the ability to open a system directory picker 
> we'd add a corresponding .openDirectoryPicker() function.

So you wouldn't be able to pick a file and a directory as in the example 
above? That seems unfortunate...


> In my prototype implementation it took around 30 seconds to build the 
> FileList for a directory of 200,000 files with a top end SSD

Wow. That's... not great in a UI.


> so depending on what the page is doing, directory picking could take 
> some time. To allow content authors with styled <input> to provide 
> feedback to users during scans of large directory trees we plan to have 
> openDirectoryPicker return a ProgressPromise:
>    
> https://github.com/slightlyoff/Promises/blob/master/ProgressFuture.idl
> 
> We'd then fire progress events at the promise specifying how many files 
> had been processed so far.

I feel very uncomfortable with the idea that we'd intentionally have an 
expensive API like this. But I guess I don't really know what the use 
cases are, so it's hard to evaluate.



Anyway, I don't have a better suggestion right now. What has the 
implementation experience been like so far?

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

Received on Thursday, 29 August 2013 20:21:08 UTC