Provide actual filename of downloaded files rather than e.g. download.jpg

[gabuzi]

Feature request

Hi!

In our pipeline, we take care to name images uploaded to elabFTW in a meaningful way. The reverse process, e.g. downloading an image by dragging&dropping them from elabFTW into a local folder or through "save image as", will create files named like download.jpg. Likewise, clicking "save link as" on an attached PDF suggests to save the file as "download.pdf".

The behavior is reported for elabFTW 4.3.10, tested on Chromium 98.0.4694.0 and Firefox 104.0.1.

It would be quite convenient for consistency to have a straightforward way of downloading images with their originally stored name.

Thanks!

I'm using the hosted version or I have PRO support: NO

[NicolasCARPi]

I've seen this too. For PDF, if you click the link on the name of the pdf, you'll see that the correct name appears on saving. But if you click the thumbnail, then the name is incorrect.

For images it seems both cases fail to provide the correct name for download. This can probably be fixed. I'm requalifying this issue as a bug report rather.

[NicolasCARPi]

Ok I figured out the bug. The Content-Disposition header was only set when forceDownload was set (on pdf for instance), because it was needed to force the download. Now I also set it for other files that can be displayed in the browser but with inline disposition. And now the correct file name is shown upon saving!

[gabuzi]

Cool, thanks a lot! Looking forward to hypernext :)

[gabuzi]

Hi!

Thanks for implementing and constantly improving the app!

It took a while for me to get back to this. The issue is resolved when opening an image from the attachments section and then right-click 'save image as...' in Firefox.

However, what I tend to do (which seems more natural to me) is to drag and drop images from the body of the displayed experiment to a folder on the mac or use the 'save as' method. Doing this now results in unnamed_file.<ext> being saved, so it seems like this issue has not been fully resolved!

We're still on 4.5.13, but judging from the changelog, it doesn't look like there was a recent change that would have changed this for 4.6.x.

[NicolasCARPi]

I am not sure how the browser can pickup the filename on a drag out action or right click save as. Do you have an example web app that does that to provide?

[gabuzi]

I tracked it down to a difference in how the href attributes is set. In the attachment section, where drag&drop works, there are additional get parameters like storage and name in addition to the f for download.php. These are missing in the main text of the experiment if you add an image there.

In my quick tests, simply appending &name=canbeanything will lead to the browser picking up that name, which then also be used for storing on the file system after drag&drop. In my tests on MacOS 13, I found that you can even leave the extension away or put a wrong one, and it will be set to the correct one after drag&drop (probably from the MIME type).

So in summary, it may be as simple as adding the proper &name= parameter to the href attributes for images displayed in the body.

[NicolasCARPi]

Done!

[gabuzi]

Sorry, it took a while for me to update to recent versions. The following was tested with 4.8.3.

I've tested and the solution does work for images inserted via the attachments section below the editor and then selecting 'insert in text at cursor position'. However, if you drag&drop an image from the filesystem directly into the editor (not into the drag&drop area), the 'name' attribute is not set in the html and the file shows as 'unnamed_file'.

Further, if you use the 'edit filename' function in the attachments section, the name param in the body are not updated accordingly and thus downloaded filenames for files taken from the text body will be wrong and remain as they were at insert-time.

So it seems like the solution is a bit more tricky and must involve updating img src attributes when anything changes.

Thanks a lot for the continuous updates!