entries-api
entries-api copied to clipboard
WICG
Behavior with mismatching absolute paths
In Chrome, if you drop a folder named upload it is given the full path /upload
From the DirectoryEntry, if you call getFile() with absolute paths you get different results:
-
/upload/foo→ NotFoundError -
/other→ EncodingError -
/other/foo→ EncodingError
Spec says it should be NotFoundError for all of these. Can we get away with that?
Chrome also responds with EncodingError for "invalid" paths (embedded U+0000 or U+000B). Would prefer TypeMismatchError or TypeError there.
@aliams @bakulf @smaug---- — is anyone going to copy Chrome's use of EncodingError here (for compat reasons)?
I'd like to clean it up in Chrome and return something more sensible instead. It "falls out" of our implementation but is definitely not intentional.
It is, or was, unclear to me when Chrome throws EncodingError. It happens so often at least on linux that many testcases don't work. Same tests do work on FF (linux/osx/win) and Edge (win).
It was even hard to write tests which pass on Chrome on linux, so when implementing this stuff I choose the option "make the expected thing to work and not copy Chrome here." What is the reason why Chrome throws so easily?
And there are open chromium bugs about this issue, IIRC.
I'm not sure why you were seeing unexpected exceptions (rather than just a dumb choice for an exception). Repro steps would be great.
You may have been seeing one of:
- webkitEntries not populated when using input.onchange event
- Accessing (copied) dataTransfer.items outside drop event returns 0 length DataTransferItemList
As far as why EncodingError shows up so much: behind the scenes paths get composed into URLs against an internal (isolated) filesystem instance. (Chrome FileSystem API supports URLs into it). If the URL isn't valid (e.g. embedded \x00) we'll generate an EncodingError. But there are also code paths where the actual cause of the failure is dropped on the floor .
There is also https://bugs.chromium.org/p/chromium/issues/detail?id=463089#c15
I'll try to find the testcase which was failing for me...
I haven't repro'd myself, but apparently Chrome does odd things with ... as path elements. Chrome internally uses a file path type for real native paths that is aware of OS quirks, which and so it may forbid ... even in cases where that shouldn't matter (e.g. when uploading from Linux). Just FYI - please don't copy Chrome's quirk here!