It may be that an inline fallback is needed here to work nicely.

It may not be easy or robust to be able to check if you have the "file editing" permission from javascript. If I force file editing off in Chrome (Settings, Privacy, Permissions, File Editing) and then change this function in filesender-config.js.php to just return false then the fallbacks are triggered and I can download a file.

So another option would be to allow an admin to force this to off if their browser policy is to disallow it. That is assuming that the permission can not be reliably tested for in JS.

window.filesender.config.isFileSystemWritableFileStreamAvailableForDownload = function() {
return false;
//    return 'showSaveFilePicker' in window;
};

An alternate I have been testing is waiting to get to decryptDownloadToBlobSink and checking for the NotAllowedError at that stage and if present then recalling decryptDownload with FSWF support forced to off. I will take a closer look at the options as doing it this alternate way is a bit loopy. It works ok in the browser from the user perspective, if decryptDownload is updated to not reprompt for the password on recursive call.

Though the alternate I have might be more kludgey than moving to the await calls up front as in this PR. Good to explore options though. :)

A real shame there doesn't seem to be a sync API to ask "do I have permission to call window.showSaveFilePicker".

Thank you for making the pull request!

As there are a number of changes already in development I think I will delay merging this until after the next release. I might make the next release 2.60 which will have the database updates and performance improvements in it. After that and a period of time for possible bugfix updates then I will turn attention to merging this and retesting the download paths with it.

Thank you for the thorough review and for considering this PR in the next releases plan.

release 2.60 (and release 2.61 due to release process) are now out. 2.61 on the 16th. If things remain quiet on the 2.61 front I will look at merging this in the next week or two.

I see a regression on Safari. Downloading an encrypted file goes from showing the download % on the download page to downloading everything in the background with no progress and only showing on completed. I haven't dug into the diagnostics to see why this is the case yet. Just an A/B of this PR vs development with a macos client + safari.

EDIT: Actually no. I had a branch without the evt. revert in it that I readded here. With that Safari is fine.

This is in 2.62. Thanks again for investigating things and making this PR!