Specify how filenames from the OS map to File's name property

[andreubotella]

I've been testing how files coming from the OS get exposed as File objects, and in particular how filenames that aren't in the OS's default encoding get mapped to the name property.

In Windows systems, filenames are sequences of UTF-16 code units (not UTF-16 encoded text, as is sometimes claimed, because the system APIs don't check for lone surrogates), and as expected, they directly map to a DOMString. An initial BOM doesn't get removed. There doesn't seem to be any browser differences here.

In Unix systems (tested on Fedora Linux; my understanding is all other modern Unix variants/distros work the same), filenames are byte sequences, which are usually taken to be UTF-8. Here's how the various browsers behave on them:

• Firefox does the equivalent of UTF-8 decode without BOM, decoding bytes which aren't valid UTF-8 as a replacement character.
• WebKit does the equivalent of UTF-8 decode without BOM or fail, and handles failures by returning a File object with the empty string as filename, empty contents, and MIME type application/octet-stream instead. The language around name in the spec might allow for an empty string to substitute a filename that cannot be decoded, but it doesn't allow the content to be dropped. Note that the resulting File object is identical to the File object that HTML's "construct the entry list" creates when a file input has no selected files.
• Chrome also does the equivalent of UTF-8 decode without BOM or fail, except that for file inputs, any file whose filename isn't UTF-8 gets dropped from the selection. For drag and drop, Chrome behaves the same as WebKit.

Since it doesn't seem good to drop files or replace them by an empty file, even when their filenames don't match the OS's conventions, it seems like it would be best to agree on Firefox's behavior.

[mkruisselbrink]

I agree that dropping files entirely is probably not ideal, and dropping file content definitely isn't. Not sure if how file names are mapped from the OS to the name property should be specified; that really seems more like an implementation detail to me.

I once started trying to spec some of this a little bit better as part of #154, i.e. see https://pr-preview.s3.amazonaws.com/w3c/FileAPI/pull/154.html#create-a-file-backed-file-object with my thought being that the html spec for input type=file and drag&drop would then call out to that to create actual File objects. Currently that just has the name conversion being done in a "user agent defined manner", and is otherwise pretty hand-wavy about OS integration as well. I think that should be good enough though.

From an implementation side, fixing this in chrome is somewhat tricky as it will require some fundamental changes to how File objects are created. These are changes we want to make anyway, but unfortunately isn't likely to happen in the near future.

[andreubotella]

It's fine if things are left implementation-defined, but maybe it'd be worth it to add a note about expected behavior:

Although the conversion from a native filename into a string is implementation-defined, it is expected to be a straightforward mapping. In particular, if the system's filenames are represented as sequences of code units, the resulting strings should be identical; and if they are represented as byte sequences, they should be decoded from the OS's default encoding with the "replacement" error mode.

I think at the very least the spec should make clear that the empty string fallback should be for OS errors when reading the filename – decoding the filename should always succeed.