Intent to Implement: Writable Files

Skip to first unread message

Marijn Kruisselbrink

Aug 10, 2018, 5:32:46 PM8/10/18
to blink-dev,, storage-dev

Contact emails,


Design doc/Spec

No design doc/spec yet. Implementation-wise this will largely be taking Chrome’s existing filesystem API implementation (used for sandboxed FS API, drag/drop, and apps/extensions API) and wrapping it in a new API. The biggest questions will be around the permissions model to use.

We haven't requested a tag review yet, but will do so soon once we have a little more clarity around the permissions/security model we're proposing.


An API similar in functionality to the existing chrome.fileSystem.chooseEntry API, but as a standard web platform feature, making it possible to write things like document editors as PWAs. This includes open files and folders for read and write access, saving files to a user selected location, and persisting references to files/folders to later access again.


Today, if a website wants to create experiences involving local files (document editor, image compressor, IDE, etc.) they are at a disadvantage to native apps. A web site must ask the user to reopen a file every time they want to edit it. After opening, the site can only save changes by re-downloading the file to the Downloads folder. A native app, by comparison, can maintain a most recently used list, re-save and even auto save, and save files anywhere the user wants.


Interoperability and Compatibility

We've heard from other browsers that there is interest in this use case. For example when discussing the sandboxed file system API in the past we've gotten feedback that the API was outdated and that just sandboxing would be as important of a use case as native access. This API tries to address both of those concerns by coming up with a more modern API.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: This has been a frequently requested feature.


It's unclear exactly how we'll integrate this feature with existing features such as input type=file, drag&drop etc, although the same primitives are used where possible (Blobs, Files, FileReader, etc).

At least this new API will be designed in such a way (using promises etc) to make it possible to introduce asynchronous steps and permissions checks in many different places, so using this API shouldn't cause any performance issues for Chrome.


Developers have been using the very similar chrome extensions API for years, so hopefully they won't have problems using this improved web-platform version of essentially the same API either. We'll also be launching this API using (one or more) origin trials, so should be able to figure out any issues in that process.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes (although the UX might be somewhat different on Android where there is less of a concept of a file system and file pickers aren't as common).

Is this feature fully testable by web-platform-tests?

Getting this feature fully tested by web-platform-tests is going to require some kind of hooks to let the test get the result of showing a file picker, as well as ways to let file system operations fail. It's unclear at this point what those hooks should look like, and it might not be feasible to test everything in this manner. If we do include support for sandboxed filesystems in the API at least the parts of the API that don't deal with file pickers should be more easily testable.

Link to entry on the feature dashboard

Requesting approval to ship?


Reply all
Reply to author
0 new messages