Implement subset of File System Access API

[Zipdox2]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: File System Access API
• Specification or proposal URL: https://fs.spec.whatwg.org/ and https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API
• Caniuse.com URL (optional): https://caniuse.com/native-filesystem-api
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1246236
• Mozillians who can provide input (optional):

Other information

This was previously turned down (#154 and Daasin@91a1e8c), however, I took notice of the "Mozilla could be supportive of parts" part. I think that this API could provide some specific very important functionality that is not harmful to the user. Please don't close this issue without reading it thoroughly and considering my case.

I think the primary concern with the API is the window.showDirectoryPicker() method and the associated FileSystemDirectoryHandle. Selecting a directory would allow a website to create and delete any number of files within the directory, and I agree that this is very dangerous, and should not be implemented (or disabled by default).

But I believe that window.showOpenFilePicker() and window.showSaveFilePicker() and the associated FileSystemFileHandle don't create any increased risk to the user than already exists today. This allows only access to one file. Opening and saving files is already possible without this API, but it doesn't provide the same functionality. The only possible problem is a website writing to a file that the user opened, because opening a file traditionally only implies reading, but this can be solved by simply prompting the user. Of course a prompt wouldn't be necessary for files created with showSaveFilePicker, since that already implies writing.

Why I think this is important is because FileSystemFileHandle allows streamed downloads for client-generated files. Currently, doing this requires a hack with service workers, which are not accessible in private mode and require a worker script to be hosted (see https://github.com/jimmywarting/StreamSaver.js). Without this you're limited to downloading files that fit within memory. Additionally, it allows seeking within a file and truncating the file.

TL;DR: Implement only FileSystemFileHandle and not FileSystemDirectoryHandle.

[jimmywarting]

Opening and saving files is already possible without this API

Same could be said for reading folders as well. (but not writing)
You can drag and drop a folder into a website and call item.webkitGetAsEntry()

Clients can update the content in that folder and website can read the newly updated files and folder in that directory with the old entry api (as long as you have not GC it)
(And you can't store this entry in IndexedDB either)

You can also get all files (recursively) by using <input type="file" webkitdirectory> (which also is available in FF)

So in some since i think that parts of showDirectoryPicker() could be allowed as well.
...at least for just reading the files for the duration of that browser session. (so you would not be able to create new files/folders so that would instead reject the promises)

[Zipdox2]

It's the writing part that's actually important here.

[martinthomson]

Thanks for raising the issue, but after discussion, we've concluded that we need to defer this question.

The idea that there might be elements of the specification that are safe to use is not one that we've explored fully. That said, we try to avoid taking specifications à la carte, because that makes it harder to manage interoperability, especially when it results in more complicated feature detection.

If we were to consider this idea, we'd like to see a more thorough analysis. That means a crisp definition of what is included, the implications of those choices, and more extensive work on understanding all of the implications (privacy, security, usability, alternatives, feature detection, interaction with other features, use cases and demand). There are potentially good mitigations already in place for some of the risks that have been identified (like a web site modifying a file that is actively in use by another program), but we'd need to see a more comprehensive treatment. Also, it's not clear that this would be responsive to the requests from web developers.

I understand that this is asking a fair bit, but it is generally accepted that the proponents of new web features do this sort of work. Opening an issue on this repository isn't the place I'd recommend taking that work, either. The WHATWG processes for new proposals are better suited to handling this sort of thing.

[goldwaving]

Implementing some form of a File System Access API is inevitable. There is no other way to efficiently modify large files or sets of files (audio, video, AI models, etc.).

[Zipdox2]

Implementing some form of a File System Access API is inevitable. There is no other way to efficiently modify large files or sets of files (audio, video, AI models, etc.).

I agree.