annevk
commented
1 year ago The WebKit post was written shortly after https://github.com/whatwg/fs/commit/f520f358297623914436bd1f8e00271b6e1bf22d so that might simply not have been taken into account. I'll see if we can clarify the post. (Edit: it's been clarified.) WebKit tracks the WHATWG File System Standard.
I agree that it's been quite confusing, but the idea is straightforward:
- The WHATWG File System Standard defines the core infrastructure that has cross-browser buy-in.
- The WICG File System Access API builds on that with local file system access and is only tracked by (some?) Chromium-based browsers.
js-choi
This issue is about the Origin Private File System (OPFS) API and CanIUse’s entry for “File System Access”.
It would be informative for developers if these links were added to the Resources tab for File System Access:
In addition, this line:
…probably should be changed to something like:
Eventually, we should split CanIUse’s entry on File System Access into (1) an entry for FileSystemSyncAccessHandle with OPFS (implemented by Chromium, WebKit, and soon Firefox) and (2) an entry for non-sanboxed File System Access (including both FileSystemSyncAccessHandle on non-sandboxed files and showOpenFilePicker etc., and implemented only by Chromium).
Background
CanIUse currently classifies Origin Private File System (OPFS) under the entry for File System Access (see #6570)…despite its description saying: “API for manipulating files in the device's local file system (not in a sandbox).”
OPFS’s situation is pretty confusing for developers, due to unclear distinctions between the File System Access incubator spec, the File System WHATWG standard, and the FileSystemSyncAccessHandle API (the latter of which would enable, e.g., SQLite using files from storage). File System Access builds on File System, it is File System and not File System Access that defines OPFS, and the FileSystemSyncAccessHandle API is seemingly defined in both File System and File System Access. File System Access also defines systems for allowing websites to non-sandboxed files, along with FileSystemSyncAccessHandle (which, again, is also defined in File System).
Safari has implemented FileSystemSyncAccessHandle specifically for OPFS files. The edit: old version of the WebKit announcement article confusingly refers to this as implementing “File System Access with [OPFS]” but does not refer to the “File System” standard in which FileSystemSyncAccessHandle and OPFS are defined. [Edit: After feedback from @annevk shortly after this issue’s post, the new version of the WebKit article now refers to the “File System API” rather than the “File System Access API”.]
At the same time, Mozilla has evaluated the general “File System Access API” to be Harmful, which includes not just the FileSystemSyncAccessHandle API but also systems for allowing websites to non-sandboxed files. However, Mozilla has given positive responses specifically to the OPFS “subset” of FileSystemSyncAccessHandle, and it is actively implementing “OPFS”.
To add to the confusion, Mozilla’s announcement of its intent to prototype “OPFS” calls out Safari’s announcement about “File System Access with OPFS”…while confusingly saying that they are implementing OPFS from the File System API and rejecting File System Access in general. This seems to mean that they are implementing FileSystemSyncAccessHandle with OPFS but not non-sandboxed files.
Furthermore, Mozilla has added a “Firefox position: positive” entry to its standards positions for “File System” (see mozilla/standards-positions#614 and https://github.com/mozilla/standards-positions/issues/562#issuecomment-1036459446), and Mozilla’s intent is to include FileSystemSyncAccessHandle (with OPFS) in its positive position on “File System” and not in its negative position on “File System Access”. (@annevk: “Note that the linked issue is technically for AccessHandle [with OPFS] which will be part of this [File System] standard (but are not yet). It seems good to have a position on the full [File System] standard that will eventually include it.”)
Exacerbating the confusion is that Google’s developer guidance on OPFS refers to the File System Access API but not File System API.
The MDN overview article for FileSystemFileHandle’s API also refers to “File System Access” and not “File System”.
Lastly, the Chrome Platform Status entry for “File System API” actually refers to the older File and Directory Entries API, a completely different API. Chrome Platform Status also has an entry for “File System Access API”, which seems to track FileSystemSyncAccessHandle for both OPFS and non-sandboxed files (i.e., both File System API and File System Access API).
All in all, this is a very confusing situation for developers:
The current CanIUse entry for “File System Access” conflates all of these separate concepts. The end result is that the CanIUse currently might give developers the erroneous impression that Mozilla will not implement FileSystemSyncAccessHandle, even for OPFS, and the erroneous impression that that OPFS (and FileSystemSyncAccessHandle) are part of File System Access but not File System.
It might be a good idea to eventually split the CanIUse’s entry on File System Access into (1) an entry for FileSystemSyncAccessHandle with OPFS (implemented by Chromium, WebKit, and soon Firefox) and (2) an entry for non-sanboxed File System Access (including both FileSystemSyncAccessHandle on non-sandboxed files and showOpenFilePicker etc., and implemented only by Chromium).
As a stopgap for now, simply adding those three links from the beginning of this issue to the current “File System Access” entry may help clarify the confusing situation a bit for developers.