Define File's type better (getFile())

[annevk]

It seems for OPFS at least this doesn't need to be implementation-defined.

[a-sully]

Given the following code:

let root = await navigator.storage.getDirectory();
let fileHandle = await root.getFileHandle('image.png', { create: true });
let file = await fileHandle.getFile();
console.log(file.type);

The latest stable versions of the major browsers logs:

• Safari: 'image/png'
• Chrome: 'image/png'
• Firefox: ''

So we should probably either:

• use some dummy value (as Firefox seems to always do), or
• create an algorithm which infers the mime type from the file extension (as Safari and Chrome seem to always do)

It seems like the latter algorithm should exist anyways in https://w3c.github.io/FileAPI/. That the Blob spec doesn't give any indication as to how a Blob's type is inferred is a known problem: https://github.com/w3c/FileAPI/issues/43#issuecomment-346922144

The Blob spec does give file type guidelines, which are supposed to apply only to "real" files on disk. In practice, it seems like these guidelines are applied to more than just "real" files, though (at least on Safari/Chrome).

One option is to point the getFile() algorithm in to those guidelines for now - which would still technically mean the type is implementation-defined, though by a specific well-established procedure - and then once https://github.com/w3c/FileAPI/issues/43 is resolved (perhaps by defining a mapping of file extension to mime type, as proposed in https://github.com/w3c/FileAPI/issues/51?) re-use that algorithm here?

curious if others have thoughts @jesup @szewai @inexorabletash @mkruisselbrink

[a-sully]

FWIW it looks like drag-and-drop for files uses "application/octet-stream" as a default value

The only restriction seems to be that it must be ASCII lowercase, but otherwise is just refers to the (unhelpful) File spec

[annevk]

The problems with type are a bit separate from this problem I think (at least those discussed in File API issue 43). I don't think the actual MIME type is inferred at the moment for File objects, except when they come from disk. Can you give a counter example?

[a-sully]

I don't think the actual MIME type is inferred at the moment for File objects, except when they come from disk. Can you give a counter example?

let root = await navigator.storage.getDirectory();
let fileHandle = await root.getFileHandle('image.png', { create: true });
let file = await fileHandle.getFile();
console.log(file.type);

This still logs 'image/png' in Chrome in incognito mode, when the "file" is in-memory. I don't have all the historical context here (@inexorabletash please feel free to chime in), but my guess is that this behavior (i.e. inferring mime types for File objects based on the extension, regardless of whether the file is on disk) has been in place in Chromium at least since earlier APIs like webkitRequestFileSystem().

[inexorabletash]

FWIW, our mapping: https://source.chromium.org/chromium/chromium/src/+/main:net/base/mime_util.cc

See also: https://github.com/w3c/FileAPI/issues/51

Decisions about where in the processing to apply the mapping predate me, so definitely before the WebKit/Blink split.

[annevk]

@a-sully that is an example using File System, against which I reported this issue. 😊 If this also exists with just the File object I agree we can say it's a larger problem, but if it only surfaces here we should tackle it. And to be clear, I mean outside of <input type=file> or drag & drop from the OS, as in those cases there clearly is a type of sorts.