Persistent file and folder handles

[ulf75]

Context

We have a dental CAD/CAM PWA, and we are importing cases from other intraoral scanner vendors. They provide the upper/lower jaw as 3D triangulations in the STL, OBJ or PLY format, and those files are in one folder. We have three methods of importing:

1. Drag & Drop into the canvas
2. Click on a “Choose Folder” button
3. Drawer menu on the left-hand side of the app, where we show all cases and patients inside a specific “Default Import” folder.

After importing we create a restoration (e.g. crown) which fits into the situation. During this process we have to export multiple files into the same folder. But we also want to export the final restoration files into another “Default Export” folder.
If you want, you can watch those videos for further clarification:

1. https://www.cad-ray.com/wp-content/uploads/2021/06/Clinux_Missing_Cusp-1-EN.mp4
2. https://www.cad-ray.com/wp-content/uploads/2021/05/Clinux_Multiple_Case_Collage-02.mp4

The first video shows a complete walkthrough a difficult case. The second video shows multiple cases fast-forward but right in the beginning you see the pop-up messages (import method 1 drag & drop).

Problem

As you can imagine, we heavily deal with multiple folders and files. But for every case after restarting the browser or tab or app (which occurs ALL the time), the user gets those messages again. And even more problematic is the import method 2 by clicking on the “Choose Folder” button. We bring up the standard folder import dialog, the user chooses a folder and then he gets two (2) messages: first for read rights and then for write rights (because we need to write files inside this folder). When we now want to export to a “Default Export” folder, a third (3) message pops up!

This is absolutely user unfriendly and raises a lot of support requests at our hotline because the users are unsure about this messages. For me this is a BIG problem.

In addition, at every start of the app we check whether there are new cases available and if yes present them to the user - we need persistent folder handles here too.

Furthermore, we want to be called by a third party program on the same computer with some additional query parameters like https://chairside.clinux.pro?folder=path/to/the/folder while the path is inside our “Default Import” folder, and automatically import this case - we need persistent folder handles here too.

Solution

In order to close the PWA gap, in my opinion having persistent file/folder handles is a crucial part.

I see here three possible solutions:

1. Make the folder handles domain-wise persistent.
2. Make the folder handles domain-wise persistent: in the pop up message there could be a checkbox like “Do not show this warning again for the clinux.pro domain.”. You can always check whether it is the correct domain.
3. Make the folder handles domain-wise persistent at least for a while: in the pop up message there could be a checkbox like “Do not show this warning again for 1 month for the clinux.pro domain.”. You can always check whether it is the correct domain, and raise a new pop up after a month. I don't think this will bother our customers that much.

Further requirements

• It must work for multiple handles: in my case for the “Default Import” and “Default Export” folder.
• It must work in the app as well as in the browser.

I originally come from C++ fat client development (where this is build-in 😉), so I hope I explained everything correctly. If not, maybe someone with more browser experience can help me out.

[yuriyDeneha]

Absolutely agree! it will be great to have such functionality available.
From UX perspective the users will enjoy to have that simplified.

[ftreesmilo]

@ulf75 That is so cool, I am so happy to see companies like yours take a bite out of the bleeding edge of PWA tech and really drive it like a native app would... Hopefully Google will oblige and start giving us some apis that perform better, even if it is only in an "installed" pwa setting.

[ftreesmilo]

@ulf75 depending on your desired use case... there is another filesystem api you could try out that's in origin trials. It requires no user consent but does not let them pick a folder (chrome handles that, stored in the user's profile dir).

You could provide the user with the ability to "download" their built files and save them elsewhere...
It's an option... might save you some grief while you wait for google to address the problems here.

I've heard talk of a merge of apis, but I'm not sure where they are with that. Check out the explainer for the other api here: https://github.com/WICG/storage-foundation-api-explainer

[tomayac]

I've heard talk of a merge of apis, but I'm not sure where they are with that. Check out the explainer for the other api here: https://github.com/WICG/storage-foundation-api-explainer

(See the article for more details: https://web.dev/storage-foundation/.)

[ulf75]

@ftreesmilo & @tomayac : thanks for your input and links - I'll check them now...

[ftreesmilo]

Is this a duplicate of #297 ?

[mkruisselbrink]

This does seem similar to #297, yes. Our current plan is to not have any changes at the spec/API level, but on the implementation side change how long a permission remains valid. Installed PWAs in that model will have permissions last much longer than today, and even for regular websites we want to avoid reprompting for the same permissions if a permissions was granted/used not too long ago (on the order or hours), to deal with browser restarts, tabs closing/reopening, etc.

[ulf75]

@mkruisselbrink : Thanks for the feedback! Do you already have an idea when this change will go live?

[sadikyalcin]

This will be a game changer for web apps. The below is my use case and considering dropping my desktop app to be replaced by a PWA if it was possible;

Download and delete large files; PDF's, videos and zips in a specific folder - users does not necessarily need to access it outside the app. It is all managed by the user within the app. I need persistent storage and with permanent permission.

The downloads are managed by the user too. They only need to download if they want to available for offline use. The only exception are the images of articles which I manually store for offline use.

[Jaifroid]

Our current plan is to not have any changes at the spec/API level, but on the implementation side change how long a permission remains valid. Installed PWAs in that model will have permissions last much longer than today, and even for regular websites we want to avoid reprompting for the same permissions if a permissions was granted/used not too long ago (on the order or hours), to deal with browser restarts, tabs closing/reopening, etc.

Nearly a year later, any update on this plan? It's really needed, at least for installed PWAs, IMHO.

[tomayac]

Please star https://bugs.chromium.org/p/chromium/issues/detail?id=1011533 to be updated on progress. Thanks!