pipcet Reporter
	Description • 7 years ago

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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 2 • 7 years ago

.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?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 3 • 7 years ago

Look for issue 4 in https://wicg.github.io/entries-api

	pipcet Reporter
	Comment 4 • 7 years ago

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!

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 5 • 7 years ago

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.

	pipcet Reporter
	Comment 6 • 7 years ago

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)

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 7 • 7 years ago

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.

	pipcet Reporter
	Comment 8 • 7 years ago

(In reply to Olli Pettay [:smaug] from comment #7)
> Chrome's behavior feels like a bug to me. Odd inconsistency in the API.

I've dug a little, and it seems to me the whole thing is a fairly obvious bug, reported in 2012 as chromium bug 139897: https://bugs.chromium.org/p/chromium/issues/detail?id=138987. The code attempts to create an isolated file system only on drops, not on selection events, but as far as I can tell it always fails to provide any usable file system object at all. When a selection event occurs after a drop, the old file system object is reused, which would presumably be an issue and allow/make the javascript code access the wrong files, but luckily the file system is so broken you can't even read its entries.

> 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.

Thanks for the advice. I've done that at https://github.com/WICG/entries-api/issues/15.

So:
 - it's a bug in Chromium
 - it's been unfixed for 4.5 years, and there appears to be little interest in even looking at it
 - Chrome, Firefox, and the spec all behave very differently
 - emulating the Chrome behavior (allowing selections after drag-and-drop, and providing unusable filesystems) seems pointless
 - the spec requires that drag-and-drop and selections behave the same

Given all that, I don't really see the point of staying with our current implementation of not-quite-Chrome's behavior.

I would like to propose that we implement the behavior the spec suggests, possibly behind a preference, but I'm not sure whether the right thing to do is to reopen this bug, file a new feature request, or accept that it's not going to happen.