5 ms·

I agree - the File System Access API with full integration with local files and folders is essential for desktop web apps. Ours[1] supports File System Access f

I agree - the File System Access API with full integration with local files and folders is essential for desktop web apps. Ours[1] supports File System Access for saving and opening projects in Chromium-based browsers, and our stats show a full 65% of users save that way. So it's also what real people actually want to use in browsers. [1] https://www.construct.net https://www.construct.net

tgv 4y ago
I'm basically against the browser getting too much access, so what is missing in Firefox 111 for your use case? Is it just less convenient for end-users?
- AshleysBrain 4y ago
  The key is the file and folder picker methods (showOpenFilePicker() etc), allowing the web app to interact with existing files and folders on the device. OPFS does not allow that, as it's internal storage in the browser, like IndexedDB.
  - cxr 4y ago
    Browsers have been able to get access to files on disk for longer now than many Web developers have even had careers—drag and drop was one of the first HTML5 APIs. Same with client-side processing for `<input type="file">` elements. (Directory access through the `webkitdirectory` attribute is another story, but it did eventually gain support from all major browsers—even if it's terribly named and the scary warnings about how it will "probably" go away on MDN haven't been updated.) As for writing, you don't get unlimited unchecked writes the way that Chrome's proposed Filesystem Access API grants you, but you can trigger "checked" writes (that show a file save dialog) using `<a/>` elements with the `download` attribute. This is arguably a better user experience, because it keeps the user in the loop, giving them the opportunity to veto (or rename/relocate) the written file—which will be difficult or impossible to do if the Chrome team's proposed API became standard. Overall, the File System Access proposal is a bad one that gets the developer vs user prioritization wrong (favoring the convenience and satisfaction of the former over preserving control for the latter), and I hope it doesn't become either a de facto or a de jure fixture of the Web platform soon. Here's to hoping for a future post to the Chrome Developers blog announcing that this is yet another experimental API of theirs that they have decided is going to be sunset in some future release.
    - nine_k 4y ago
      This is not access to the filesystem. This is access to some controlled contents that happen to come from the filesystem, with interaction explicitly initiated by the user every time. It gives the browser no access to the structure of the filesystem, no way to navigate it, and crucially no way to transparently read or write anything. This is good isolation, I'd prefer it to be this way. OFS also gives equally good isolation, I'm fine with that. Sharing between OFS and the rest of the user's file system should be possible, but only explicitly, a la iOS, Android, and the file upload / download dialog.
      - cxr 4y ago
        Please follow the discussion; we are not referring to the narrow "origin private file system" here. > This is not access to the filesystem. Wrong. I know what "this" is, thanks, and it is access to the filesystem. That's because "this" here—in the subthread you have just posted to—refers to Chrome's experimental implementation of the larger proposal (which is literally called "File System Access API"), not the limited subset described by the submission as having just gotten enabed in Firefox.
        nine_k 4y ago
        Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute, which are not filesystem access. While Google's new API definitely is.
        cxr 4y ago
        > Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute It's the `download` attribute, but yeah, I understand the significance of those words. I wrote them. Your replies in this thread, on the other hand, are confusing at best. What are you actually trying to communicate?
  - worksonmine 4y ago
    What's wrong with <input type="file" /> and the $HOME/Downloads folder? Why is arbitrary access to a whole folder needed? Cool, yes. Dangerous? Very.
    - daveoc64 4y ago
      That's how you end up with "March 2023 Report (Final) (Edited) (3).docx". Making users repeatedly upload and download the same file to work with it is clunky.
      - throw0101b 4y ago
        > That's how you end up with "March 2023 Report (Final) (Edited) (3).docx". People having been doing that with Word and other local word processors using (SMB) file shares for decades. There's nothing special about web browsers that's causing it.
        comex 4y ago
        People using Word in this manner typically create a new filename only occasionally, not every single time they save. Browsers, on the other hand, will create a new filename every single time a download is initiated. That makes downloads impractical to use as a web app’s sole persistence mechanism; a few smaller web apps do so anyway but it’s rare. And if they’re not the sole persistence mechanism, if downloads are just an export option separate from a ‘normal’ save, like you see in most web apps, then the 99.9% of users who don’t constantly export all their documents will have to deal with the consequences of the normal persistence mechanism. That is probably cloud storage, with associated centralization, privacy, and cost concerns, though it could also be browser-local temporary storage (cookies / localStorage / IndexedDB / origin-private file system), with reliability and portability concerns.
      - worksonmine 4y ago
        I'd rather have the inconvenience of clicking the file I want to overwrite than accidentally giving a web-app access to something I didn't intend to. Making mistakes should be hard and intentional.
account42 4y ago
> So it's also what real people actually want to use in browsers. I am a real person and I don't want this.
- afavour 4y ago
  The OP already said 65% of users, it’s implicit that 35% of users don’t want to use it. It’s unclear to me why the views of you or that 35% should override the majority.
  - unxdfa 4y ago
    65% of people who were asked with what question and what panel and what information provided? This whole idea is stupid. Another C program with and ability to run arbitrary code off the network written by idiots and nasty folk being given arbitrary filesystem access. Have we learned nothing? We need more controls (MAC / process sandboxing) not less. Just because someone wants to do something to make their lives easier and asks a set of people what they want who says yes doesn't mean it's a good idea. I say this as someone who has written desktop/web integration stuff over the years without this.
    - AshleysBrain 4y ago
      The File System Access API does not grant arbitrary file system access. At most it provides access to a folder manually chosen by the user, with limits on which folders can be accessed (e.g. root or entire documents folder is not allowed).
  - Xelbair 4y ago
    It is unclear why the views of 65% should be also pushed onto me.
    - afavour 4y ago
      You’re free to not use it?
  - 4y ago
mihaaly 4y ago
> desktop web apps ....what?! ... World Wide Web Desktop? World Wide Web on my desktop? My desktop on the World Wide Web? There must be some confusion here. : ) If an app becomes desktop app why the heck using a browser?
- charcircuit 4y ago
  Because the web solved app distribution and sandboxing before desktop operating systems did.
danaris 4y ago
I'm a real person, and I'm deeply concerned by a) the way Chrome is trying to become the de-facto "standard" for web apps and bully or dare the other major browsers into following suit or being seen as "out of date", and b) the level of access Chrome is trying to give to itself and web apps running in it. Google is already very clearly exercising its market dominance in search and other areas to try to gain ever more of our attention and data. I'm insufficiently informed about the differences between File System Access API and Origin Private File Access to have an opinion on which of those I think is a better choice, but please remember that Your Experiences Are Not Universal.
- dugmartin 4y ago
  The Origin Private File Access API seems to be a subset of the File System Access API. You can see Firefox 111 has been added to the browser compatibility chart here for most features: https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API?#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/File_System...
bombolo 4y ago
Perhaps your sample is biased?

tgv 4y ago

I'm basically against the browser getting too much access, so what is missing in Firefox 111 for your use case? Is it just less convenient for end-users?

AshleysBrain 4y ago
The key is the file and folder picker methods (showOpenFilePicker() etc), allowing the web app to interact with existing files and folders on the device. OPFS does not allow that, as it's internal storage in the browser, like IndexedDB.
- cxr 4y ago
  Browsers have been able to get access to files on disk for longer now than many Web developers have even had careers—drag and drop was one of the first HTML5 APIs. Same with client-side processing for `<input type="file">` elements. (Directory access through the `webkitdirectory` attribute is another story, but it did eventually gain support from all major browsers—even if it's terribly named and the scary warnings about how it will "probably" go away on MDN haven't been updated.) As for writing, you don't get unlimited unchecked writes the way that Chrome's proposed Filesystem Access API grants you, but you can trigger "checked" writes (that show a file save dialog) using `<a/>` elements with the `download` attribute. This is arguably a better user experience, because it keeps the user in the loop, giving them the opportunity to veto (or rename/relocate) the written file—which will be difficult or impossible to do if the Chrome team's proposed API became standard. Overall, the File System Access proposal is a bad one that gets the developer vs user prioritization wrong (favoring the convenience and satisfaction of the former over preserving control for the latter), and I hope it doesn't become either a de facto or a de jure fixture of the Web platform soon. Here's to hoping for a future post to the Chrome Developers blog announcing that this is yet another experimental API of theirs that they have decided is going to be sunset in some future release.
  - nine_k 4y ago
    This is not access to the filesystem. This is access to some controlled contents that happen to come from the filesystem, with interaction explicitly initiated by the user every time. It gives the browser no access to the structure of the filesystem, no way to navigate it, and crucially no way to transparently read or write anything. This is good isolation, I'd prefer it to be this way. OFS also gives equally good isolation, I'm fine with that. Sharing between OFS and the rest of the user's file system should be possible, but only explicitly, a la iOS, Android, and the file upload / download dialog.
    - cxr 4y ago
      Please follow the discussion; we are not referring to the narrow "origin private file system" here. > This is not access to the filesystem. Wrong. I know what "this" is, thanks, and it is access to the filesystem. That's because "this" here—in the subthread you have just posted to—refers to Chrome's experimental implementation of the larger proposal (which is literally called "File System Access API"), not the limited subset described by the submission as having just gotten enabed in Firefox.
      - nine_k 4y ago
        Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute, which are not filesystem access. While Google's new API definitely is.
        cxr 4y ago
        > Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute It's the `download` attribute, but yeah, I understand the significance of those words. I wrote them. Your replies in this thread, on the other hand, are confusing at best. What are you actually trying to communicate?
- worksonmine 4y ago
  What's wrong with <input type="file" /> and the $HOME/Downloads folder? Why is arbitrary access to a whole folder needed? Cool, yes. Dangerous? Very.
  - daveoc64 4y ago
    That's how you end up with "March 2023 Report (Final) (Edited) (3).docx". Making users repeatedly upload and download the same file to work with it is clunky.
    - throw0101b 4y ago
      > That's how you end up with "March 2023 Report (Final) (Edited) (3).docx". People having been doing that with Word and other local word processors using (SMB) file shares for decades. There's nothing special about web browsers that's causing it.
      - comex 4y ago
        People using Word in this manner typically create a new filename only occasionally, not every single time they save. Browsers, on the other hand, will create a new filename every single time a download is initiated. That makes downloads impractical to use as a web app’s sole persistence mechanism; a few smaller web apps do so anyway but it’s rare. And if they’re not the sole persistence mechanism, if downloads are just an export option separate from a ‘normal’ save, like you see in most web apps, then the 99.9% of users who don’t constantly export all their documents will have to deal with the consequences of the normal persistence mechanism. That is probably cloud storage, with associated centralization, privacy, and cost concerns, though it could also be browser-local temporary storage (cookies / localStorage / IndexedDB / origin-private file system), with reliability and portability concerns.
    - worksonmine 4y ago
      I'd rather have the inconvenience of clicking the file I want to overwrite than accidentally giving a web-app access to something I didn't intend to. Making mistakes should be hard and intentional.

account42 4y ago

> So it's also what real people actually want to use in browsers. I am a real person and I don't want this.

afavour 4y ago
The OP already said 65% of users, it’s implicit that 35% of users don’t want to use it. It’s unclear to me why the views of you or that 35% should override the majority.
- unxdfa 4y ago
  65% of people who were asked with what question and what panel and what information provided? This whole idea is stupid. Another C program with and ability to run arbitrary code off the network written by idiots and nasty folk being given arbitrary filesystem access. Have we learned nothing? We need more controls (MAC / process sandboxing) not less. Just because someone wants to do something to make their lives easier and asks a set of people what they want who says yes doesn't mean it's a good idea. I say this as someone who has written desktop/web integration stuff over the years without this.
  - AshleysBrain 4y ago
    The File System Access API does not grant arbitrary file system access. At most it provides access to a folder manually chosen by the user, with limits on which folders can be accessed (e.g. root or entire documents folder is not allowed).
- Xelbair 4y ago
  It is unclear why the views of 65% should be also pushed onto me.
  - afavour 4y ago
    You’re free to not use it?
- 4y ago

mihaaly 4y ago

> desktop web apps ....what?! ... World Wide Web Desktop? World Wide Web on my desktop? My desktop on the World Wide Web? There must be some confusion here. : ) If an app becomes desktop app why the heck using a browser?

charcircuit 4y ago
Because the web solved app distribution and sandboxing before desktop operating systems did.

danaris 4y ago

I'm a real person, and I'm deeply concerned by a) the way Chrome is trying to become the de-facto "standard" for web apps and bully or dare the other major browsers into following suit or being seen as "out of date", and b) the level of access Chrome is trying to give to itself and web apps running in it. Google is already very clearly exercising its market dominance in search and other areas to try to gain ever more of our attention and data. I'm insufficiently informed about the differences between File System Access API and Origin Private File Access to have an opinion on which of those I think is a better choice, but please remember that Your Experiences Are Not Universal.

dugmartin 4y ago
The Origin Private File Access API seems to be a subset of the File System Access API. You can see Firefox 111 has been added to the browser compatibility chart here for most features: https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API?#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/API/File_System...

bombolo 4y ago

Perhaps your sample is biased?