-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rejection behavior for legacy branch #41
Comments
Note that the directory listing by default is not recursive, that is, if your directory only contains other folders, nothing will be shown. If you, however, have files in it, it will work: You can also enable recursive mode, but careful since this can be a heavy operation depending on how deeply your folders are nested: const options = {
// Set to `true` to recursively open files in all subdirectories,
// defaults to `false`.
recursive: true,
};
const blobs = await directoryOpen(options); |
@tomayac It doesn't work even if I select directories that contain an image file. |
I tested this on Firefox 86.0.1 (64-bit) on macOS 11.3 Beta (20E5210c). Can you let me know your platform? Do all Open * buttons not work for you, or just some? Can you paste the output of the |
Sure thing!
|
Thanks for the details. It turns out the problem was a code race with the previous |
It works now with selecting the file and clicking on open (in the file select dialog) but.. In my project I get the following error: On https://browser-fs-access.glitch.me/ there is no message in the console.. but it doesn't open the file. |
Could this be just Firefox specific? Could you test with this demo and let me know? It was working fine for me on Windows, but sometimes macOS required me to deselect and reselect the file before it would work.
Yes, this is to be expected, you need to catch the exception: try {
const file = await fileOpen();
} catch (err) {
console.log(err.message);
}
I just tested this successfully on 86 and 87. Could you try again? Note that the demo filters on images. |
EDIT:
On Firefox 87 Windows 10 it doesn't work with double click on file but works with file select + open. Using the "Open Image File"-Button on https://browser-fs-access.glitch.me/ |
Sorry.. little mistake..
I thought the demo linked to https://browser-fs-access.glitch.me/ .. On the normal Just as info, I am using now the old version of this library. |
The latest version 0.16.0 rejects, too, but without the focus hack. See specifically browser-fs-access/src/legacy/file-open.mjs Lines 33 to 49 in c188acd
|
double click file select in open file dialog on firefox windows:
|
|
The behavior from 0.16.0 is the best-possible solution we can come up with given that there is no proper cancel event. It rejects upon the first page interaction upon canceling the dialog. |
@tomayac There is a hiccup here. If I use this library in Chrome but at a URL that uses Should I make a new issue for the above? |
the reject-thing is pretty broken (the last time i tested it) and there is
no clean solution for it (i think).
having a reject when the user selects a file is in no way the best-case for
me.
i am using an older version with the missing-reject, having no reject is
the better-case.
it's just something you need to know and probably leaks something in the
background but still the better solution (for me).
|
Answering to @KoKuToru and @jmrog's comments above:
Oh no. This is unfortunate. Is enforcing your site to load over HTTPS a workaround? if (!isSecureContext) {
location.protocol = 'https:';
} Note that the library also exposes a
I rename the present Issue and re-open it.
I more and more am convinced that there is indeed no clean solution that works universally.
Would making the rejection behavior be configurable be a workable option for either of you? |
Thank you both for the replies.
Not at present, unfortunately. It's a longer term goal, but we're not there yet.
For us, this would be perfect. We're currently inclined to think that we should reject very "lazily" rather than "greedily" -- e.g., not reject at all (which would leak, as @KoKuToru notes, but it would be very tiny), or perhaps reject only after a very long amount of time and/or a number of events are recorded. Our app needs to act when a file is actually opened, but it doesn't really need to do anything in the event of a cancel. |
@tomayac Unsure whether it conforms with what you were thinking, but the PR above is a rough thing I threw together to allow configurably handling cancel/rejection in the legacy branch. It would work well for us. Any thoughts there? Here is how you could use the API in the PR for custom behavior:
|
Fixed via #45. |
I have just released v0.17.0 that includes the new configurable behavior. (Note that I have also added this to the |
Thanks, @tomayac! We'll be upgrading to the latest version today. @KoKuToru This should also allow you to upgrade. If you still want no rejection ever with the legacy API, you can just make the new const file = await fileOpen({
setupLegacyCleanupAndRejection: () => () => {},
}); But of course you now also have the option of rejecting/cancelling very late (e.g., on timeouts, clicks, focus change, or route changes). I'm interested in how/whether it works for you! |
The example site at https://browser-fs-access.glitch.me/ doesn't seem to work on Firefox v86.0.1. The pickers all appear properly, but after selecting files or a directory, nothing happens. Is this intended?
The text was updated successfully, but these errors were encountered: