This API enables developers to build powerful apps that interact with other (non-Web) apps on the user’s device via the device’s file system. After a user grants a web app access, this API allows the app to read or save changes directly to files and folders selected by the user. Beyond reading and writing files, this API provides the ability to open a directory and enumerate its contents, as well as store file and directory handles in IndexedDB to later regain access to the same content.
During the second origin trial for these features we primarily focused in fine-tuning the shape of the API, better aligning with the rest of the web platform. A summary of these changes can be found at https://github.com/WICG/native-file-system/blob/master/changes.md.
If no other browsers end up implementing this API, websites using it won't work in them. Usage of a wrapper such as https://github.com/GoogleChromeLabs/browser-nativefs will let websites use this new API while falling back on other (less user friendly) approaches when not available.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/154)
WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-August/031347.html)
Web developers: Positive (https://discourse.wicg.io/t/writable-file-api/1433)
Wrapper libraries such as https://github.com/GoogleChromeLabs/browser-nativefs will make it easier for websites to take advantage of this feature, while gracefully degrading to what was possible without this API in browsers that don't yet support it.
Letting websites write to (and read from) arbitrary files on disk is inherently dangerous. This risk is mitigated by blocking access to particularly sensitive/dangerous locations (such as those containing chrome, or operating system files). Additionally all written files are run through safe browsing checks in exactly the same way regular downloads are. More details in https://wicg.github.io/native-file-system/#privacy-considerations and https://wicg.github.io/native-file-system/#security-considerations.
No additional devtools or other debugging support has been added specific to this feature.
For debuggability purposes it would be nice to expose more about handles than is exposed to script (such as what actual files on disk a handle corresponds to). Additionally we have a long-standing bug (https://crbug.com/256067) to bring devtools support to the sandboxed/private file system API.
No This API is currently only supported on Desktop platforms (i.e. Windows, Mac, Linux and Chrome OS). Mobile platforms have moved away from the model of having multiple applications share a file system to interact with the same data in favor of Share actions, and as such the current entry points this API defines are a poor fit for Android. In the future we might introduce other entry points using the same interfaces that are a better fit for Android/mobile platforms.
Most of the API surface has tests: https://wpt.fyi/results/native-file-system?label=experimental&label=master&aligned In addition to the tests listed on wpt.fyi we also have manual tests that exercise the API surface the host operating's native file system as opposed to the sandboxed/origin private file system, and in chrome these manual tests are also run automated. Actual integration with file dialogs on various platforms is not currently testable in an automated fashion.
This intent message was generated by Chrome Platform Status.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVZpphZcq2YP4DV94YvrqBPxERf8%2BZyc8rANvSHDPuyiSA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD649j5LSpEfw%3DzDC6j_T67TH3t%2BBzVYAoe6DgB5azVvjWFTVw%40mail.gmail.com.
Super-nit: the first sentence of this explainer says "are yet to be decided" - presumably it's been decided now? :)
Otherwise I like this explainer, it was easy to read and understand.To what extent has this spec changed greatly since the last review from TAG, other vendors, or others in the W3C / WHATWG community? Your last comment on the TAG review mentions "a number of API changes in response to feedback we received", have some of those happened very recently and so might need some time for re-review?
You also explicitly called out two issues about the API shape (issues 210 and 192) that you want TAG review on. If those change it's definitely breaking, so it would be very good to get feedback on those issues before shipping.
On Wed, Aug 19, 2020 at 6:22 PM Chris Harrelson <chri...@chromium.org> wrote:Super-nit: the first sentence of this explainer says "are yet to be decided" - presumably it's been decided now? :)Good catch, fixed.
Otherwise I like this explainer, it was easy to read and understand.To what extent has this spec changed greatly since the last review from TAG, other vendors, or others in the W3C / WHATWG community? Your last comment on the TAG review mentions "a number of API changes in response to feedback we received", have some of those happened very recently and so might need some time for re-review?Most of the API changes were directly or indirectly incorporating earlier TAG feedback (i.e. integration with the permissions API, multiple separate file/directory picker methods as opposed to one method with a bunch of options/different return types). Most of these changes were made ~a month ago. 217 was a change that was made very recently (this week), in response to Mozilla feedback that getOriginPrivateDirectory was not a very good name.You also explicitly called out two issues about the API shape (issues 210 and 192) that you want TAG review on. If those change it's definitely breaking, so it would be very good to get feedback on those issues before shipping.Re 210, I'm fairly confident of the decision we ended up making there. Every version of the spec (i.e. any version the TAG would have looked at) has had file picker methods directly on the global, which was never raised as a concern. I also discussed this with a former TAG member, who expressed a preference for keeping things that way rather than introducing some kind of namespacing. So I think what we ended up doing (i.e. keeping file picker methods directly on the global) is the right choice.Re 192, is API surface wise just a single method, behaving fairly similar to the various existing methods to get drag&drop data. So with that in mind it seemed simple enough to include, as it doesn't seem like there is much room to do anything different there. But I can see the argument that perhaps we should delay shipping the drag&drop integration until people have had a bit more of a chance to play with this/provide feedback, as this is functionality that hasn't been part of the origin trials (it has been one of the top requests during the origin trial though).FWIW, from discussions at TPAC last year it seemed that some people at Mozilla were fairly supportive of the direction we were taking with this API, but those are different people from the people that have participated in the standards position discussion.
Spec mentor (newly minted!) weighing in here -Like most specs, the work is never quite done. The remaining spec issues called out inline and on github - covering normative and non-normative TODOs - are unlikely to affect interop with sites. In particular, it could use Accessibility and Internationalization Considerations sections added, and integration with other infrastructure specs such as Storage is ongoing, but I wouldn't consider those blocking for shipping.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVa21kc-Hd%2BsFbOUdGFcJe1B7q3g9nhshV3gZZmbTG7rsw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjpOzHp%2BG_uM6bOLxdSrNrw63OXyatDo7zkJxEjKYeAWg%40mail.gmail.com.
I like the single/multiple file handle parts of this. The directory parts make me nervous. I hope to hear some about what the security review considered and how they see this.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8qCph0V-apHDCRoLFVJczf0gk1komubv%3DG%3DckzvGF%3DQg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e93d902e-3bf8-8aec-d5b0-54cd50bb5b25%40gmail.com.