Add an id to chooseFileSystemEntries for tracking last directory

[AshleyScirra]

Often applications will use chooseFileSystemEntries for two distinct purposes, such as opening a document, and exporting content in a different format. Typically the user will open a document from one folder (e.g. 'Documents'), and export to another (e.g. the desktop). Similarly they may open different types of content from different locations, or save different types of content to different locations.

To improve the user experience, it's useful if chooseFileSystemEntries remembers the last folder the user was in. This means if they tend to open files from the same folder (e.g. 'Documents'), the file picker tends to default to the right place.

However if chooseFileSystemEntries is used for distinct purposes, the browser has no good way of remembering the right folder. For example if an application provides options for 'Save document as...' and 'Export as PDF...', these will both use 'save as' dialogs, with little to distinguish them from the call to chooseFileSystemEntries. Therefore the browser cannot remember their state separately. The end result is if the user alternates between "save as" and "export", it defaults to the wrong directory, forcing the user to navigate back to the folder they want every time.

An easy way to solve this is just to add an arbitrary string "id" to ChooseFileSystemEntriesOptions, e.g.:

chooseFileSystemEntries({
    "type": "saveFile",
    "id": "document"
});
// ... and somewhere else ...
chooseFileSystemEntries({
    "type": "saveFile",
    "id": "export"
});

Now the browser can always remember the right default location for each distinct use of chooseFileSystemEntries. It could also use the ID to save other state associated with the window.

[mkruisselbrink]

Interesting ID. I definitely want to explore more around default locations to start a file picker in, and this does seem like a useful API addition in that regard.

[AshleyScirra]

For reference this is basically equivalent to FileOpenPicker.SettingsIdentifier in the Windows UWP platform (which is also used on FileSavePicker and FolderPicker).

[guest271314]

To improve the user experience, it's useful if chooseFileSystemEntries remembers the last folder the user was in.

That can have unintended consequences #71 (that still persist).

When <input type="file"> is used before chooseFileSystemEntries() the initial directory opened for selection is the directory selected by <input type="file"> even though the two APIs are expected to be operating independently. The observable issue is that when the above occurs "prompt" will be set as value for permissions instead of "granted" when chooseFileSystemEntries() is executed. There needs to be a means to clear any previous selection for both <input type="file"> to the degree that the File API indirectly impacts the Native File System API and for the case of users that have the requirement to not track, store a reference in memory, or open any previously opened directories.

[AshleyScirra]

the two APIs are expected to be operating independently

Are they expected to operate independently? The user doesn't care which API is used behind the scenes, and the user would ordinarily expect their last used settings to be remembered.

[guest271314]

Are they expected to operate independently?

Yes. File API is not Native File System API. Neither specification states that the previously selected directory will be "remembered" nor does the specification state how to expressly not "remember" the previously selected folder.

The user doesn't care which API is used behind the scenes, and the user would ordinarily expect their last used settings to be remembered.

How do you know that? Did you run a study and have empirical evidence to support that claim? Or are you basing the claim on your own pure speculation? Not in this case. The expectation is the exact opposite based on the fact the behaviour is not specified.

In this case expect the exact opposite as neither specification states that will occur and further causes "prompt" to be set as permission instead of "granted" resulting in the fact that it is not possible to first select a file from <input type="file"> then when chooseFileSystemEntires() is called to navigated from the previously selected folder to the directory where the directory is selected - even though user action MUST be ongoing during that navigation.

[AshleyScirra]

How do you know that? Did you run a study and have empirical evidence to support that claim?

I haven't done a study or collected empirical evidence, but I have been designing, developing, publishing and maintaining consumer software for about 10 years, and users regularly bring up this type of thing. Hopefully that counts as more than just speculation. I mean, don't you prefer to have software remember where you left things? For example if you always choose a non-default directory, isn't it preferable that the last directory you used is remembered rather than making you navigate to it every time? It's a straightforward bit of UX, and hopefully we don't have to go to the trouble of a full usability study for something like this. (I certainly haven't seen that this is a requirement of the other bits and pieces of spec work I've been involved in).

I don't see the harm in simply leaving the default directory unspecified, other than as proposed here, where the last directory for a given id is remembered (probably per-origin too).

[guest271314]

I haven't done a study or collected empirical evidence, but I have been designing, developing, publishing and maintaining consumer software for about 10 years, and users regularly bring up this type of thing.

Individual experience is a fact to that person. That does not mean individuals outside the range of your experience have the same expectation.

I mean, don't you prefer to have software remember where you left things?

No. At any given time could be running several unrelated tests of various APIs, workarounds for implementations and specifications, proof-of-concepts, et al. No API should leak data into another API without being explicitly and clearly specified that is the intended output. Instead of being observable as a bug.

Have no objection to specifying a directory to open. The browser already "remembers" the directory being opened from a different API. What do have concern about is the opposite requirement: do not "remember" any directory. The two should be specified together, to prevent the issue described that persists.

Unless you can point to such language there is no reason why any developer should expect File API <input type="file"> directory selection to have an affect on Native File System API. Perhaps if you reproduced the bug yourself might be illuminating to your perspective. Perhaps not. In either case, if this proposal does become specified there is no reason why the same proposal would not include a definitive means to not "remember" any previously selected directory, from both this API and File API or any other API which is capable of selecting directories.

[guest271314]

@AshleyScirra To reproduce the issue am describing run this code https://github.com/guest271314/native-messaging-mkvmerge before clicking "Connect" and "Send" click <input type="file"> element and select a Matroska or WebM file (there is a .webm file in the repository) stored in a directory different from "native-messaging-mkvmerge" directory, a similar if not the same case described in the language within this proposal

Typically the user will open a document from one folder (e.g. 'Documents'), and export to another (e.g. the desktop)

then use the URLs embedded in placeholder at the HTML <textarea> element value, click "Connect", then "Send", select "host" directory in "native-messaging-mkvmerge" folder.

What will occur is the the file system chooser will open the directory the .webm file was selected from, the user then needs to navigate within file manager GUI to the "host" directory, which ultimately results in an exception citing the erroneous message "user activation" being thrown and permission set to "prompt" even though it cannot be disputed that the user MUST click at least once to select "host" folder, meaning there IS "user activation". In any event that bug means that it is not possible to proceed from <input type="file"> to Native File System when the directory to be selected for the latter API is different from the directory selected by the former API. If you arrive at a different conclusion, post the code which achieves the expected output.

[AshleyScirra]

I think you're conflating two issues:

1. The default folder displayed by the file picker
2. The fact an additional permission prompt is required after choosing a directory

AFAICT number 2 is the same as issue #89. It can be worked around - you need to get another user gesture. In our PWA we use queryPermission to see if write access will prompt, and if it does we show a new dialog that states permission is required, and requests it when the user clicks OK. It works but requires two permission prompts, which is what #89 is aimed at solving.

[AshleyScirra]

For the record, here's a blog post about SettingsIdentifier that also clearly explains the purpose of the feature: https://devblogs.microsoft.com/oldnewthing/20200525-00/?p=103789

[mkruisselbrink]

#261 has a proposal for an API for this, feedback welcome.

[AshleyScirra]

It looks like the proposed id property would indeed cover this. (It applies to all types of file/folder pickers, right?)

[mkruisselbrink]

Yes, that is my proposal at least.