UX: add an option for downloads to go into /tmp that people can actually find
Categories
(Firefox :: Downloads Panel, defect)
Tracking
()
People
(Reporter: el, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Steps to reproduce:
In response to https://bugzilla.mozilla.org/show_bug.cgi?id=1738574 it seems some option was added in some way for downloads that are set to open with a program (rather than "save to file") go back into some /tmp folder again. However, in Settings > Files and Preferences > Downloads there is no obvious way to do so. Even worse, about:config also doesn't show any useful setting when I search for "downlods". This here mentions an option: https://github.com/mozilla/policy-templates/blob/master/README.md#startdownloadsintempdirectory but when I manually add an about:config entry browser.downloads.start_downloads_in_tmp_dir with boolean set to true, this doesn't actually seem to do anything.
Actual results:
- I tried to use the supposedly added option to have downloads opened with a program go to /tmp again since I find it way more intuitive
Expected results:
I am able to find such an option despite it supposedly being available now. This was not the case, I can't find it.
I think a good place would be Settings > Files and Preferences > Applications and then a checkbox below stating "Retain downloads permanently when Open File as used". Ideally I'd say it should be unchecked by default since just conceptually that makes way more sense to me, but given all the discussions I'm assuming the devs won't like that. But even if it's checked by default, at least it'd be possible to easily find the option and uncheck it then.
My bad, I meant to write "Retain downloads permanently when Open File was used".
|
||
Comment 3•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Downloads Panel' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 4•3 years ago
|
||
This was considered at the time and we actively decided not to do it. We don't think most users will be able to consider the up/downsides of toggling the option (not least that it just won't work right without a lot of other work, on linux snap builds, which are now the default on some large distros). I don't think anything has changed that would change our opinion.
FWIW, it sounds like most of your annoyance is that you didn't realize the option existed, and that the option "doesn't actually seem to do anything"? We have automated tests that the option works, so it is surprising that it would not, so I think that would be worth investigating (ie to have more details about what exactly you did, what file you downloaded in what way (did you open manually from an "always ask" dialog, or have the filetype set to always open, etc.), what you expected, and what happened instead).
Well, what is the option? Can't you at least add it (disabled) to the default about:config listing? I mentioned above what random things I tried, but I don't even know if anything of that was something that should have done anything.
(And to clarify further, no, my annoyance is not that I didn't knew that it existed. I heard it supposedly exists, I spent 15 minutes googling trying to find out more, and STILL couldn't manage to activate it. Don't you think that's maybe a problem? I think it is...)
Oh, maybe just figured out what maybe happened:
-
Maybe my Firefox version, the dev edition (so it's not nightly, although reasonably) new was too old, in any case, about:config didn't list it.
-
I manually entered it as described above. However, I typed it as above in the readme: https://github.com/mozilla/policy-templates/blob/master/README.md#startdownloadsintempdirectory it says browser.downloads.start_downloads_in_tmp_dir
-
I just checked again, the option IS listed now, likely due to an update, but listed as: browser.download.start_downloads_in_tmp_dir (Note the browser.download. vs browser.downloads.)
In conclusion, it looks like the README I linked above is wrong and could use some updating(?), unless I'm missing something. Beyond that, maybe my browser version was just too old since now it is actually listed. I suggest that the README is updated since it seems to be the only somewhat easy to find mention in the search engines. That should help anyone finding it in the future.
This is just a very uninformed note at the end, but I would still suggest a UI listing however. While maybe the user can't judge the implications easily, who can of the current state either? I think if anything the takeaway of all the discussions was that it seems to depend too much on specific circumstances what works better, so why not give some more obvious control to just see what works. You could always still disable it from showing up in the snap version, or maybe try to nudge canonical to do something about it. /tmp not working as expected seems like a more wide-ranging problem. But I don't know much about the details so maybe I'm wrong, apologies in any case.
|
|
||
Comment 8•3 years ago
|
||
(In reply to Ellie from comment #7)
Oh, maybe just figured out what maybe happened:
- Maybe my Firefox version, the dev edition (so it's not nightly, although reasonably) new was too old, in any case, about:config didn't list it.
Right - if the pref doesn't show up in about:config, that version of Firefox did/does not support it. Without a time machine, this is not a fixable problem, of course...
- I manually entered it as described above. However, I typed it as above in the readme: https://github.com/mozilla/policy-templates/blob/master/README.md#startdownloadsintempdirectory it says browser.downloads.start_downloads_in_tmp_dir
There is a typo here, as you discovered. This reflects a code typo that was made when the enterprise setting (that was meant to modify the pref) was originally added, which was rectified in bug 1772001. Because the readme you linked is not in our central repository, I did not realize that it had copied the typo but been left un-corrected. I have now submitted https://github.com/mozilla/policy-templates/pull/956 to correct this. Thanks for flagging this up.
Either way I'm glad you got this to work, and I'm sorry it was a rubbish experience to get there. Unfortunately, I don't think that changes my view on whether we should expose this setting in the UI.
Description
•