`queryPermission()` shouldn't return "prompt" when a handle retrieved from idb no longer exists on drive

[ZYinMD]

In my app, the user grants permission to a folder, then I store the handle in idb. On the next launch, I retrieve the handle and call requestPermission() to ask for permission again.

Goal:
I want to avoid showing the folder picker window. Since the folder location probably didn't change, showing the folder picker is an unnecessary step, and negatively affects user experience if the user don't remember to previous location they used.

Problem:
If the folder has been deleted / renamed / moved, the page will still prompt for permission to the old location. If the user clicks "agree", the subsequent read / write will fail, only then will I know the folder is gone, and show a picker again. This is confusing to the user.

Solution:
After a handle is retrieved from idb, there should be a way to test if it still exists on drive, and browser should be able to test that without requiring user permission. If the old location is still there, then I can request user permission. If the the old location is gone, I'll display a picker.

(This may open doors to certain ways of abuse, but we can devise some restrictions)

Proposal
If the handle no longer exist on drive, maybe let queryPermission() return 'denied'?

[jimmywarting]

this is useful but i do thing that denied could also be confusing for both the end user and the developer

a developer might show a message saying something in terms of "you have dined us from trying to read the folder xyz, try again?"
something more better would be to know if it have been explicitly removed so that we can instead show a message "xyz have been moved, deleted or renamed from the filesystem and could not be located, pick another folder to where it have been moved to or delete this entry"

[ZYinMD]

Currently queryPermission() returns "denied" | "granted" | "prompt", we could add a 4th one called "missing".

[a-sully]

The API's permissioning model is mostly indifferent to what's actually happening on disk, in part because the underlying file system can change at any time. I'd be hesitant to provide any information about the state of the file (such as "missing") in a permission query, since that may no longer be accurate by the time you want to do something based on that information (TOCTTOU).

whatwg/fs#30 attempts to address this by being explicit that a FileSystemHandle simply maps to a path. If the path no longer exists (for example, the handle has been move()d) it was really permission to the path which mattered anyways so still having access is expected behavior.

Change events, proposed in #72, will hopefully soon fill the gap here by notifying the site when the underlying file system changes

[jimmywarting]

I think "missing" could be fitted for other things as well like await navigator.permissions.query({name: 'camera'})

you could for instance only have a usb-webcam and if you unplug it then you no longer have it.

[a-sully]

Any changes to PermissionState would fall under the Permissions API. You're welcome to file an issue on that spec, but that is outside the scope of this API :)