Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 27 users
Status: Available
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment
.webkitEntries not populated when using input.onchange event
Project Member Reported by, Jul 25 2012 Back to list
1. Use <input type="file" multiple> and select multiple files
2. I'd expect each FileEntry to be included in .webkitEntries, but the length is 0.

Selecting a single file (w/o multiple), populates .webkitEntries with the FileEntry.

Note: dragging multiple files onto a <input type="file" multiple> works as expect. That is, 
all FileEntries are include.d
Comment 1 Deleted
Looks like onchange in general doesn't work when the user selects from the file dialog.
 Issue 139114  has been merged into this issue.
Summary: .webkitEntries not populated when using input.onchange event (was: NULL)
Comment 5 by, Sep 10 2012
Any updates on this one? Currently only a FileList can be retrieved from the onchange event, but it is not as convenient as getting a list of Entry objects.
Currently I'm only relying on drag-and-drop to get a hold of these entries, but it would be nice for this bug to be addressed, among other things to be able to use a button on mobile scenarios where there is no drag-and-drop ;)
Comment 7 by, Oct 4 2012
Comment 8 by, Oct 18 2012
Labels: -Feature-Filesystem WebKit-Storage-FileSystem
It's also important for packaged apps. Particularly for text editors apps. All of them expect to have ability to select folders and read/write to entries via chrome.fileSystem API. Or more important is ability to choose directories directly by chrome.fileSystem.chooseEntry({type: 'openDirectory'}, function() { ... });
Another place it becomes important is when a directory has a lot of entries in it, especially when that directory is on a NAS or some other slow device. In those cases, populating a FileList may take a long time, freezing the browser and leading to a lot of resource usage. The webkitEntries approach is much less resource intensive, but as alejandro pointed out, drag-and-drop is not always available.
Project Member Comment 11 by, Mar 10 2013
Labels: -Area-WebKit -WebKit-Storage-FileSystem Cr-Content-Storage-FileSystem Cr-Content
Project Member Comment 12 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Project Member Comment 13 by, Apr 6 2013
Labels: Cr-Blink-Storage
Project Member Comment 14 by, Apr 6 2013
Labels: -Cr-Content-Storage-FileSystem Cr-Blink-Storage-FileSystem
Any chance this will be addressed in the near future?  
Is there a suggested workaround? At present it seems like drag and drop is the only means of getting a directory entry from the platform.
Using drag-and-drop is all I've come up with. Moreover, due to, there is no way at all to get an entry for the local FS into a Web Worker. This is ironic considering that one of the oft-quoted use cases for a Web Worker is to perform I/O.
I really hate dropping input type=file from an app I'm working on as it will violate the WCAG recommendation that users be able to use an application using only a keyboard -- drag and drop takes quite a bit of trickiness from the keyboard. But, this does seem the only reasonably way of working with complex directory trees with a large number of files. At this point, I guess that the "input type=file webkitdirectory" concept is pretty broken.

Comment 19 by, Jun 25 2013
is pretty broken.

I find it just an extension of 'multiple'...
Just to explain/record the "why"..

The FileEntry elements in .webkitEntries are created with respect to an isolated file system, holding only them. Codewise, it is currently only possible to create such an isolated filesystem from the drag data that the platform supplies.
Normal users will rarely use drag and drop. Please support this.
Comment 23 by, Mar 7 2014
isolated file system, holding only them. Codewise, it is currently only
possible to create such an isolated filesystem from the drag data that the
platform supplies.

That doesn't make sense, at very beginning both d&d and input only manage a
path, so both can be able to create that isolate filesystem.
Status: Available
I think this is quite important. Since we now have the ability to pass fileEntry to a NaCl plugin, it is a shame we can't use it for files opened by a HTML input field. I don't think there is currently a way to pass a file opened by the Browse button into a plugin (whereas you can do it for files dragged and dropped).
Labels: -Cr-Blink -Cr-Blink-Storage Cr-Blink-FileAPI
Seriously, this bug has been unaddressed for over 3 years now? Does the Chrome development team not want their browser's unique capabilities more widely adopted by developers worldwide?
Project Member Comment 29 by, Oct 21 2016
Labels: Hotlist-Recharge-Cold
Status: Untriaged
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit - Your friendly Sheriffbot
Status: Available
This is an inconsistency we should fix. Other browsers are now implementing Chrome's "entries api" to support directory upload and will likely not have this inconsistency.

pwnall@ - can you look into this? (not urgently, obviously)
Labels: EntriesAPI
Comment 32 by, Dec 28 2016
Actually, chromium behavior is even odder: once a file has been dropped onto the dialog, subsequent changes to the selection using the file dialog will work. This differs from Firefox, which attempted to copy the (inconsistent and against-the-spec, if I'm reading it correctly) chromium behavior.

I've filed a FF bug at, and asked for clarification of the spec at

IMHO, this is a severe accessibility issue: users should not be forced to use drag-and-drop to use a web app.
Sign in to add a comment