I thought I should discuss this with other users here before opening a github issue, because maybe I’m missing something.
The UX for the receiver of a Send is very poor. It seems like a download prompt is not raised in the browser until the entire file has been fetched, which for large files can take a very long time. This leads users to think it is not working. I’m then bombarded with complaints that they can’t download files. All they have to do is wait a while, but there is no indication (other than a spinner, which is only fractionally better than nothing) that anything is happening at all. So users have no way to know whether they should just wait or that something is broken.
Does everyone experience this? Is there a workaround? Any fixes planned?
I am unable to reproduce this behavior in a Chrome browser, for a Send consisting of a 467-MiB file (close to the 500-MiB file size limit).
For a split second after clicking on the Send link, the browser window says “Redirecting…”, and then a Bitwarden logo with a spinner is visible for 2-3 seconds:
Thereafter, the download link appears:
However, when clicking the blue download button, there is a delay of around 150 seconds (with a spinner shown within the blue button) while downloading and decryption is completed, and then the browser’s file save prompt pops up (if you have set your browser to prompt for where to save each download).
Are you sure that the delay observed by your users is actually occurring before the blue download button is displayed in the Bitwarden Send UI, or are you talking about the delay that occurs after clicking the blue button?
Thanks for that. In fact you have reproduced the issue. And really it may not be right to call it an ‘issue’, since it is presumably the expected behaviour, but it’s really not a good user experience.
My complaint is about the 150 second wait you experienced while the blue spinner shows. This is unusual behaviour and is leading many of my users to wonder whether something is not working. After all, a loading icon without any visible progress is a classic sign of something having crashed or failed.
The typical expected behaviour for downloads on almost any other service is that a download dialogue appears immediately, THEN the file downloads. If not a download dialogue, then at least the browser would start downloading to a default location.
It’s probably not the file downloadper se that is causing the delay, but the decryption of the downloaded file. Bitwarden would first download an encrypted blob (the location of which would be unimportant — it may even be saved in memory only), then decrypt the encrypted data (probably storing the results in memory again), and only then ask where the decrypted file should be saved.
I would suggest that in the Name of the Send, add text to the effect "(click blue link and then wait up to 3 min for decryption) ":
Other than that, you could submit a feature request to propose that they add a progress bar to the Send UI.
Thanks for the suggestion of including the warning in the name of the Send, I will probably try that for now. Sadly, as we know, most readers will not read anything if they can help it, but maybe it will reduce the load a little bit :).
