Intent to Implement: Writable Files
Marijn Kruisselbrink
Contact emails
m...@chromium.org, natt...@chromium.org
Explainer
https://github.com/WICG/writable-files/blob/master/EXPLAINER.md
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.
Summary
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.
Motivation
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.
Risks
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.
Ergonomics
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.
Activation
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
https://www.chromestatus.com/feature/6284708426022912
Requesting approval to ship?
No