New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 58977 link

Starred by 26 users

Issue metadata

Status: Fixed
Closed: May 2012
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Can't drag and drop a directory on file input with webkitdirectory attribute

Reported by, Oct 13 2010

Issue description

Chrome Version       : 8.0.550.0 (Official Build 62062) canary build
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
Firefox 3.x:
IE 7:
IE 8:

What steps will reproduce the problem?
1. Open above URL in Chrome canary
2. Open a file explorer
3. Drag and drop a directory onto the file input in the proved URL

What is the expected result?
The onchange event fires on the file input and outputs all file names within directory

What happens instead?
The directory is treated as a file rather than directory and outputs the directory name

Please provide any additional information below. Attach a screenshot if

The FileList object is populated correctly if I click "Choose file" and select a directory that way. 

One side note shouldn't this attribute be named x-webkit-directory according to the html5 extensibility section?

Comment 1 by, Oct 15 2010

Labels: -Area-Undefined Area-Webkit
Status: Untriaged

Comment 2 by, Oct 26 2010

when drag a directory , get a file and not all files. if you want to choose a directory,must use <input type="file" webkitdirectory="true">

Comment 3 by, Oct 27 2010

Comment 4 by, Nov 3 2010

Labels: Mstone-9
Status: Assigned
Labels: -Mstone-9 Mstone-10
Given our current velocity, we need to punt 500 bugs from m9.  Moving p2 bugs, that are not started and have an owner to the next milestone.  If this issue absolutely needs to be fixed in the current milestone please move it back, however, at this time the focus should be on p1 bugs.

Comment 6 by, Dec 9 2010

Labels: -Mstone-10 MovedFrom-10 Mstone-11
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
Labels: -MovedFrom-10 -Mstone-11 Mstone-10
Status: Started

Comment 9 by, Jan 27 2011

Labels: -Mstone-10 Mstone-11 MovedFrom-10
Move to M11 from M10, as we've now branched.  If you believe this bug was moved in error, please come talk to me.
Labels: -Mstone-11 -MovedFrom-10 Mstone-10 ReleaseBlock-Beta
This is an important issue for a client of directory upload, we should shoot for M10 if at all possible.

Comment 11 by, Jan 31 2011

How long for a fix?
Labels: -ReleaseBlock-Beta
Hi John,

Any update on this?

Got somewhat caught up on the design for this, but I am working on as minimal a patch as possible to unblock the particular use case, which will be ready today.
Labels: -Mstone-10 Mstone-11
Still working on an implementation, but the changes required for this are too complicated IMO to merge into M10 without risk.  Since I can't really justify making it a blocker, moving it to M11.

Comment 15 by, Mar 9 2011

Labels: -Mstone-11 Mstone-12 MovedFrom-11
rolling over all nonblockers from m11 to m12
Looks like there was a lot of progress on this but it stalled in mid February.  Any updates since then?

Comment 17 by, Mar 17 2011

A CL is in progress, it just needs some updates after security concerns.

Comment 18 Deleted

Labels: Review-Security
Project Member

Comment 20 by, Apr 12 2011

The following revision refers to this bug:

r81183 | | Mon Apr 11 17:01:51 PDT 2011

Changed paths:

Add a path for a web page to request the enumeration of a directory.  This, together with a WebKit change, will allow a drag-and-drop on a Directory Upload control (<input type=file webkitdirectory>) which provides only the path to the renderer, to correctly populate the control as if the user had selected that directory in a file picker.

BUG= 58977 
TEST=drag-and-drop on directory upload control (with upstream change)
Review URL:
Project Member

Comment 21 by, Apr 19 2011

The following revision refers to this bug:

r82130 | | Tue Apr 19 11:40:12 PDT 2011

Changed paths:

Change the method name from enumerateDirectory to enumerateChosenDirectory in order to match the change in

BUG= 58977 
TEST=drag a folder onto a webkitdirectory control
Review URL:

Comment 22 by, Apr 25 2011

Labels: -Mstone-12 Mstone-13 MovedFrom12
Moving out of M12.
Labels: -MovedFrom-11 -Mstone-13 -MovedFrom12 Mstone-12
Status: Fixed
This was finished before the M12 branch
When is this expected to hit Chromium? As of Chromium 13.0.749.0 (83101) Mac, it's not working.
Labels: OS-Mac
Status: Started
It was working for me on Linux but there appears to be an issue on Mac where the drop target is not recognized.

Comment 26 by, Jun 1 2011

Labels: -Mstone-12 MovedFrom12 Mstone-14
This bug was targeted for M12, but not fixed.  Moving out to M14.
Labels: -MovedFrom12 MovedFrom-12

Comment 28 by, Jul 28 2011

Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.

Comment 29 by, Sep 8 2011

Labels: MovedFrom15 bulkmove Mstone-16
moving all non-essential bugs from 15 to 16. please feel free to move back if this was an error and your bug is a release blocker.
Does anyone know if the Mac issue has been fixed yet?

Comment 32 by, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17

Comment 33 by, Dec 19 2011

Labels: -Mstone-17 Mstone-18 MovedFrom-17
Moving bugs marked as Started but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.
What's the status on this bug? It appears that D&D of directories is not working. M18 Win 7. I'd imagine this bug and code path are related.
It looks like this code shipped but never got the security review bit flipped? The desired behavior is working for me in 17 beta on Linux. Do we still need security review?
So there is a difference between Drag-and-drop a folder directly onto the File Input Element. But these days, we almost never expose the actual file input element (everything is custom UI with XHR-based uploaders).

My understanding is that the former case was handled (onto element) - I personally saw this work in a local demo some months ago.

But I don't think the latter case is working, i.e., read folder info from DnD event on arbitrary element.

My understanding is this bug never covered reading folder info in a drop event on arbitrary elements, since the attribute is specific to the file input element.

We should probably create a new bug (if it doesn't already exist) to cover arbitrary folder drag and drop.
Yes this bug only covered dropping a directory on a file input with the webkitdirectory attribute, however I would love to see the ability to drop a folder on an arbitrary element and be able to read the contents that way too.
@seddon.ryan you may want to star this issue for directory drag-and-drop on an arbitrary element: 

The issue summary is not descriptive enough but it's trying to support directory (or any combination of single/multiple files/folders) drag-and-drop both on the <input type="file"> and on an arbitrary element.

Comment 40 by, Feb 7 2012

Labels: MovedFrom18 Mstone-19

Comment 41 by, Mar 27 2012

Labels: -Mstone-19 Mstone-20 MovedFrom-19

Comment 42 by, Apr 27 2012

Labels: -Mstone-20 MovedFrom-20
These bugs have hit their limit of moves to new milestones.  Please retarget when appropriate.
Project Member

Comment 43 by, May 17 2012

The following revision refers to this bug:

r137627 | | Wed May 16 20:54:36 PDT 2012

Changed paths:

Include directories in dropdata on Mac

So that we can handle directories in drop event as well as on other platforms.

BUG= 58977 , 99823 
TEST=manually tested with LayoutTestsediting/pasteboard/data-transfer-items-drag-drop-entry.html

Review URL:
Status: Fixed
I *think* this should work on Mac after r137627.
I'm marking this Fixed for now, but please reopen if the problem still reproduces.  (And please star  issue 99823  for native drag-and-drop support)
Confirmed on Mac Ryan's original test page. Thanks Kinuko!
Project Member

Comment 46 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 47 by, Mar 11 2013

Labels: -Area-Webkit Cr-Content
Project Member

Comment 48 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment