Feedback to user on download #269
Comments
|
Yeah, it indeed looks like the file is fetch():ed first and then passed on to the browser to process only when the fetch() completes. I guess it makes sense on small files that you potentially want to show directly in dCacheView, but it's not something I would expect when I explicitly select to download it... dv.js#L635 and download-task.js seems to be the relevant code. I suspect that the correct solution would be to rip all the download stuff out and replace it with something that lets the browser do the work, which would include first opening the expected save-dialog. Or rename the current download-code to a View action and limit it to handle things that could be displayed inline in dCacheView. Since #268 is also related to download-handling, it would likely make sense to look at both issues at the same time. |
|
Also, the current download code seems prone to not report errors. Using Firefox on Linux, I tried downloading a file significantly larger than my /tmp file system since that's where the file seems to land for me before I get the save-dialog. Anyhow, I could see that a temporary file showed up, grew in size until fs was full, and then vanished. No error notification/dialog or anything. |
Currently dCacheView handles downloads by first doing the download and only when the download has completed it passes the object along for the browser to handle. The result is no feedback at all for users when initiating download of large files since the save dialog is shown on completion, and huge files might not download at all if the temporary browser download location runs out of space. Work around this by letting the browser handle the download instead, the method chosen is to create a temporary Anchor element to drive the download action as it has an explicit download attribute and avoids issues with modern browser pop-up blockers. Since username/password (Basic) auth can't be reliably passed along a short-lived Macaroon is created to handle the download. Existing Macaroons are used as-is to handle download in the shared-files view. Sessions with certificate authentication are assumed to work as-is, bypassing the Macaroon generation stage. The result is a decent end user experience when downloading files, including huge files that are common in a scientific data store. Credits go to various threads on https://stackoverflow.com/ for explaining numerous corner cases and nuances in this area. Fixes: dCache#269 Signed-off-by: Niklas Edmundsson <[email protected]>
Currently dCacheView handles downloads by first doing the download and only when the download has completed it passes the object along for the browser to handle. The result is no feedback at all for users when initiating download of large files since the save dialog is shown on completion, and huge files might not download at all if the temporary browser download location runs out of space. Work around this by letting the browser handle the download instead, the method chosen is to create a temporary Anchor element to drive the download action as it has an explicit download attribute and avoids issues with modern browser pop-up blockers. Since username/password (Basic) auth can't be reliably passed along a short-lived Macaroon is created to handle the download. Existing Macaroons are used as-is to handle download in the shared-files top-level view. Sessions with certificate authentication are assumed to work as-is, bypassing the Macaroon generation stage. The result is a decent end user experience when downloading files, including huge files that are common in a scientific data store. Missing in this patch is handling of subdirectories in the shared-files view. Credits go to various threads on https://stackoverflow.com/ for explaining numerous corner cases and nuances in this area. Fixes: dCache#269 Signed-off-by: Niklas Edmundsson <[email protected]>
Currently dCacheView handles downloads by first doing the download and only when the download has completed it passes the object along for the browser to handle. The result is no feedback at all for users when initiating download of large files since the save dialog is shown on completion, and huge files might not download at all if the temporary browser download location runs out of space. Work around this by letting the browser handle the download instead, the method chosen is to create a temporary Anchor element to drive the download action as it has an explicit download attribute and avoids issues with modern browser pop-up blockers. Since username/password (Basic) auth can't be reliably passed along a short-lived Macaroon is created to handle the download. Existing Macaroons are used as-is to handle download in the shared-files top-level view. Sessions with certificate authentication are assumed to work as-is, bypassing the Macaroon generation stage. The result is a decent end user experience when downloading files, including huge files that are common in a scientific data store. Missing in this patch is handling of subdirectories in the shared-files view. Credits go to various threads on https://stackoverflow.com/ for explaining numerous corner cases and nuances in this area. Fixes: dCache#269 Signed-off-by: Niklas Edmundsson <[email protected]>
I am not really sure what happens, but when starting the download of a larger file, no feedback is given to the user.
It looks like the file is downloaded first and the dialogue if and where you want to save this file locally appears after it is downloaded. In consequence one is tempted to start a download multiple times.
The text was updated successfully, but these errors were encountered: