Closed Bug 1326031 Opened 3 years ago Closed 3 years ago
Element .webkit Entries always empty
An HTML <input type="file">'s .webkitEntries property currently remains empty even when files are selected in the element. There is code in HTMLInputElementEntry.c to update the webkitEntries property, but it is never called except by the testing-only function MozSetDndFilesAndDirectories. I have dom.webkitBlink.filesystem.enabled = true. I'm attaching a patch that appears to work, as well as a test script that displays the .webkitEntries property. STR: open noentries.html click "Browse..." select a file in the dialog expected output: Array [ FileSystemEntry ] actual output: Array  It's probably a good idea to double-check that there are no security issues with access granted to files or directories that shouldn't be accessible before applying this.
.webkitEntries is expected to be empty when using file picker. .webkitEntries is populated when using drag-and-drop. Yes, it is super weird, but that is what is implemented in Chrome. Do you have a testcase where Firefox behaves differently to Chrome?
Look for issue 4 in https://wicg.github.io/entries-api
Thanks! I'm reading the spec differently, but if it's expected behavior this bug is invalid. Okay, I'll add a warning to the MDN article. Sorry for the non-bug!
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You may want to file a spec but to sort this out. So far our implementation (and I think Edge's implementation too) try to follow whatever crazy stuff has been implemented in blink, just to be compatible.
Actually, there is a slight difference between Chromium and FF: Chromium: open noentries.html drop a file onto the selector -> [FileEntry] click and select a file manually -> [FileEntry] for the new file FF: open noentries.html drop a file onto the selector -> [FileEntry] click and select a file manually ->  So chrome appears to "activate" the file chooser once something has been dropped onto it, then allows you to use the dialog to select a file the good old old-fashioned way, Mozilla doesn't. I can see how the chrome behavior makes sense from a security POV, particularly when directories are picked (which is hidden behind a pref for us)
Chrome's behavior feels like a bug to me. Odd inconsistency in the API. Though, everything related to webkitEntries handling is odd and full of inconsistencies. Worth to mention in the spec bug, if you file such. That is the way to get the API work the same way everywhere, including in Edge.
You need to log in before you can comment on or make changes to this bug.