Bugzilla

bug 1719892 will likely fix this for PDFs by just not saving them to disk, and opening them directly from the web (with the URL in the address bar), where the PDF.js toolbar will allow downloading permanently if the user wants that.

However, the general fact that we'll no longer save files opened with an app to `tmp` remains.

I'd like to better understand why this is an issue for folks. Is cluttering up the downloads folder the main reason they don't like this behaviour? Are there any other reasons that I'm missing?

The behaviour Firefox used to have here (before we changed it on Nightly, ie the saving to tmp + deleting) is specific to Windows and Linux, and was implemented to mimic Internet Explorer, waaaaay back in the day. Although Edge now has an option to prompt you for each download, which offers the option of opening the file, which uses the temp dir, that isn't the default. Additionally, if you configure Edge to *automatically* open a particular filetype with an external app, it goes back to saving it to the downloads folder anyway.
So pretty much everything now saves downloads to the downloads folder (which it's worth pointing out didn't commonly exist on Linux at the time this got implemented, which has also changed - though not everywhere...). 

There are downsides to automatically deleting the files and having them in a location that ordinary users find hard to discover, especially if it isn't possible or easy for them to re-download the file, and if the application used to open it restricts being able to make copies (which a number of PDF and Office applications can be made to do by settings inside the file being opened, beyond the user's control). This is probably why Edge behaves in the slightly puzzling way, where it puts files in the temp dir if you manually open them, but not if you automatically open them (which then likely still wouldn't accomplish the user goal of not cluttering the downloads folder...).

There are also technical downsides to the old way of doing this. Specially, the possibility that `/tmp` is on a different volume and/or machine (which itself causes issues on Windows), so file moves work differently and can fail late in the download (e.g. if there's space in `/tmp` but not at the destination). Then there's the fact that it doesn't work for snap/flatpak builds because of permissions issues. And on top of that, if we were to maintain both ways of doing this indefinitely, that means twice as many configurations to test (some of which we aren't in a position to easily test automatically, like the cross-machine/cross-volume moves/copies, which means that breakage is likely to go unnoticed).

I'm not wontfixing this bug right now, but I *am* saying that moving away from saving to the tmp dir was a deliberate choice, and that adding an option of sorts to go back to the old thing has a bunch of downsides, so I'm not sure it's something we're going to want to do. I would expect that it'd make more sense to ensure that we exposed more of the metadata about the download (e.g. whether it was opened automatically) to extensions, and then it'd be fairly easy for an extension to, for instance, delete all auto-opened downloads.

bug 1719892 will likely fix this for PDFs by just not saving them to disk, and opening them directly from the web (with the URL in the address bar), where the PDF.js toolbar will allow downloading permanently if the user wants that.

However, the general fact that we'll no longer save files opened with an app to `tmp` remains.

I'd like to better understand why this is an issue for folks. Is cluttering up the downloads folder the main reason they don't like this behaviour? Are there any other reasons that I'm missing?

The behaviour Firefox used to have here (before we changed it on Nightly, ie the saving to tmp + deleting) is specific to Windows and Linux, and aligned with Internet Explorer, waaaaay back in the day. Although Edge now has an option to prompt you for each download, which offers the option of opening the file, which uses the temp dir, that isn't the default. Additionally, if you configure Edge to *automatically* open a particular filetype with an external app, it goes back to saving it to the downloads folder anyway.
So pretty much everything now saves downloads to the downloads folder (which it's worth pointing out didn't commonly exist on Linux at the time this got implemented, which has also changed - though not everywhere...). 

There are downsides to automatically deleting the files and having them in a location that ordinary users find hard to discover, especially if it isn't possible or easy for them to re-download the file, and if the application used to open it restricts being able to make copies (which a number of PDF and Office applications can be made to do by settings inside the file being opened, beyond the user's control). This is probably why Edge behaves in the slightly puzzling way, where it puts files in the temp dir if you manually open them, but not if you automatically open them (which then likely still wouldn't accomplish the user goal of not cluttering the downloads folder...).

There are also technical downsides to the old way of doing this. Specially, the possibility that `/tmp` is on a different volume and/or machine (which itself causes issues on Windows), so file moves work differently and can fail late in the download (e.g. if there's space in `/tmp` but not at the destination). Then there's the fact that it doesn't work for snap/flatpak builds because of permissions issues. And on top of that, if we were to maintain both ways of doing this indefinitely, that means twice as many configurations to test (some of which we aren't in a position to easily test automatically, like the cross-machine/cross-volume moves/copies, which means that breakage is likely to go unnoticed).

I'm not wontfixing this bug right now, but I *am* saying that moving away from saving to the tmp dir was a deliberate choice, and that adding an option of sorts to go back to the old thing has a bunch of downsides, so I'm not sure it's something we're going to want to do. I would expect that it'd make more sense to ensure that we exposed more of the metadata about the download (e.g. whether it was opened automatically) to extensions, and then it'd be fairly easy for an extension to, for instance, delete all auto-opened downloads.