1738574 - Want an option to continue to use /tmp and autodelete downloads automatically opened in an application

Status: VERIFIED FIXED

(Firefox :: File Handling, enhancement)

Description

[filman230]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

In Firefox Nightly, set the settings to open PDF files directly inside Firefox (or to open with external programs with any kind of file).
Open a file this way on a webpage, using for example https://file-examples.com/index.php/sample-documents-download/sample-pdf-download/

Actual results:

The file is downloaded inside the "download" directory, instead of /tmp as it did before.
It seems that Firefox stable (v93) is not affected.

Expected results:

It may be related to this issue https://bugzilla.mozilla.org/show_bug.cgi?id=1733750, but I don't use snap (my Firefox Nightly was downloaded directly on Mozilla's website), so I'm not sure if it's actually related.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alice0775 White]

I can reproduce the issue on Nightly95.0a1 Windows10.

Before landing of Bug 1732347: the file is created in temp folder. And it will be automatically deleted when you close the browser.

After landing of Bug 1732347: the file is created in download folder. And it would not be automatically deleted when you close the browser.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=216de3cdebc9db25336b56380f23a20252d7e555&tochange=3de56e38f3c87f33a1e7849701edb3c62bc472a5

Comment 3

[:Gijs (he/him)]

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.

Comment 4

[Ray Fambro]

Just wanted to say that I agree with your rationale here Gijs. Don't feel like we'd want to go back to the old behavior (saving in the /tmp folder) as we deliberately wanted to move to a more "commonly expected" way of saving these kinds of files. We can double check that UX is in agreement with this approach on Monday.

Comment 5

[Andreas Jung]

(In reply to :Gijs (he/him) from comment #3)

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?

Cluttering the downloads folder will be an almost daily annoyance with this new behavior.

Currently:

1. Open technical bulletin 1 -> not relevant -> close the file
2. Open technical bulletin 2 -> not relevant -> close the file
   ...
3. Open technical bulletin n -> relevant -> done

New behavior:

1. Open technical bulletin 1 -> not relevant -> close the file
2. Open technical bulletin 2 -> not relevant -> close the file
   ...
3. Open technical bulletin n -> relevant
4. Clean up multiple completely useless files in the downloads folder
   They are useless right now, because they are irrelevant for the work at hand and will be so in the future because they have nonsensical file names so downloading them again when needed is easier anyway.

Also there are cases where the free (or allowed) disk space is small which makes just ignoring the contents in the downloads folder forever impossible.

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.

That's okay, but please provide the API in a timely manner in this case. Sadly often such cases ended with the API being never (or months/years later) provided in the past.

Comment 6

[putr4.s]

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?

Another reason I like the fact that those get saved to /tmp specifically is because that's just a RAM disk for me (which also appears to be true for most distros I've used, except for OpenSUSE Leap), so with the current stable behaviour files I just want to open temporarily and did not explicitly save will not eat up any of my SSD write cycles (or require spinning up my hard drive). Autodeleting them after the fact would not help for this as the damage would already be done.

I do get the issue with Flatpak/Snap not being able to access the system /tmp though, so I'd very much prefer the ability to at least change the directory these files are saved at least, so in those cases I can at least set up a custom tmpfs volume and point Firefox to that for example.

Also, where would Firefox save these files to if I have the "Always ask where to save files" option selected? I just downloaded Nightly to try and see what it does but I can't even get the "open with or save file" dialog to even pop up, it jumps to asking the location to save the file immediately, or if I do have the "Save files to" option selected it just goes and downloads the file immediately, even on things like the install button on Firefox's Flathub page for example (which works as I expected on my Firefox 94.0.1 install from the Arch Linux repos). The Nightly version I got was 96.0a1 (2021-11-18), and I'm on Arch Linux.

Comment 7

[:Gijs (he/him)]

(In reply to putr4.s from comment #6)

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?

Another reason I like the fact that those get saved to /tmp specifically is because that's just a RAM disk for me (which also appears to be true for most distros I've used, except for OpenSUSE Leap), so with the current stable behaviour files I just want to open temporarily and did not explicitly save will not eat up any of my SSD write cycles (or require spinning up my hard drive). Autodeleting them after the fact would not help for this as the damage would already be done.

On a modern SSD, write cycles really aren't that big a deal anymore - and even if they are, unless you're downloading tens or hundreds of files for every single HTML page you browse to, downloads aren't likely to be the biggest cause of writes here (compared to say, disk cache, and sqlite databases with cookies, and session restore databases, etc. etc.).

I'd very much prefer the ability to at least change the directory these files are saved at least,

You can adjust the default downloads directory, just as before.

Also, where would Firefox save these files to if I have the "Always ask where to save files" option selected?

Initially, the default downloads directory, then moved to the location of your choice (Firefox will prompt, cf. bug 1738916).

I just downloaded Nightly to try and see what it does but I can't even get the "open with or save file" dialog to even pop up, it jumps to asking the location to save the file immediately, or if I do have the "Save files to" option selected it just goes and downloads the file immediately, even on things like the install button on Firefox's Flathub page for example (which works as I expected on my Firefox 94.0.1 install from the Arch Linux repos). The Nightly version I got was 96.0a1 (2021-11-18), and I'm on Arch Linux.

This all sounds like expected behaviour to me. Full details about the changes are in this public doc. You can alter your per-filetype preferences as before in the Firefox settings/preferences, and can go back to "always ask" (the dialog) behaviour there, or set files to open immediately etc. etc.

If a filetype doesn't show up there, you can change that by right clicking a download entry for that filetype in the downloads panel or library, and clicking "always open similar files" in the relevant context menu.

Comment 8

[Romain Testard [:RT]]

Overall users will find it easier to discover downloaded files in the "Downloads" directory, this aligns with behavior from other browsers and I'm not seeing concerns that are not address with Gijs comments apart from the need for an API on Comment 5.
I'll close this bug and recommend filing a specific bug for an API request on https://bugzilla.mozilla.org/enter_bug.cgi?product=WebExtensions.

Comment 10

[mirh]

I'm still not getting it.
You can come up with all kinds of edge case for either option. Even though I must acknowledge this new behaviour is probably the most straightforward one to understand for the average joe.

But this was asking for a setting/config to toggle, not revert the default (effectively guarding you from whatever "ordinary guys" may do or think).
And putting aside the "movable folder" argument (which could apply to every folder, duh), the only legit concern seems the snap bug mentioned in the first comment.
But either as a general release pref or as a compile switch, you could have a define called say HAS_PRIVATE_TEMP or IS_SANDBOXED_ENVIRONMENT to neutralize "mismatches" between saving files and LaunchWithApplication actions.
Like, I'm sure something similar to this is already at least indirectly assumed in android builds.

Comment 11

[Timvde]

(In reply to :Gijs (he/him) from comment #3)

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?

This tends to be annoying for me because I have "Always ask you where to save files" on. If I want to save a file, it is often related to some project and I want to store it there immediately. For most other files (which is a big majority of the things I download), I basically don't care and want to open it right now and forget about it later.

I also noticed that in the case that I do choose to save a file in my Downloads folder because I don't have a better place for it, I rarely find it again just based on the file name (sorting by date can help for recent files, but looking for older files is mostly a waste of time opening many "potential" candidate files). Because it's just a dump of everything that doesn't fit anywhere else, the Downloads folder is of limited use to me and I often just end up just downloading files again. I take the extra download time just because it's easier and less frustrating to find. So for a lot of files, I learned to not even bother downloading anymore (coincidentally also decreasing the number of files in my Downloads folder and increasing the chances that I do find a file there when I need to), and this new behaviour would not only "clutter" my Downloads folder, but also massively increase the disk space taken by (duplicate) downloads.

This behaviour has actually been one of my pet peeves with Chrome since the beginning and a thing Firefox always did so much better for me :)

That being said, I do understand all the downsides for less technical users, and I agree that this is probably a better default. But I'd love to have an option to still be able to just "open" a file.

Comment 12

[:Gijs (he/him)]

(In reply to Timvde from comment #11)

This tends to be annoying for me because I have "Always ask you where to save files" on.
<snip>
But I'd love to have an option to still be able to just "open" a file.

FWIW, after the change in bug 1738916, if you have "always ask you where to save files" turned on, for files that you have set to always open with a helper app (either default system handler or a custom app), we'll save to the default downloads dir and not prompt (if you're on 97 and that's not what you're seeing, please file a bug with more details, ideally with a link where it reproduces and a copy of handlers.json from your profile). You could customize the default downloads dir to a folder you name something like "throwaway downloads" and then clean that out at regular intervals, to get more or less the same workflow as before. Hope that helps.

As outlined in comment 3, unfortunately we don't want to reintroduce the tmp option because maintaining it in addition to the new default would cause significant ongoing maintenance costs and likely break periodically because of how hard some of the edgecases are to test and because most users would not encounter it (which reduces the chance we catch things on beta/nightly). I'm not sure what the add-ons team's thinking about bug 1746880 is, which may help further alleviate the issues you're seeing (ie an add-on could clean up downloads automatically).

Comment 13

[mirh]

Can you detail some of those edge cases, hoping they aren't just snaps and users moving folders away from beneath a running browser?

Comment 14

[Timvde]

FWIW, after the change in bug 1738916, if you have "always ask you where to save files" turned on, for files that you have set to always open with a helper app

I don't open any files in an application by default, because it does not generally depend on the file type whether I want to save a file or just open it. Maybe some (most?) of the applications offer a "Save as" function, but I'd still be storing the files multiple times and cluttering my Downloads folder (making it increasingly hard to actually find files I want to keep).

As outlined in comment 3, unfortunately we don't want to reintroduce the tmp option because maintaining it in addition to the new default would cause significant ongoing maintenance costs and likely break periodically because of how hard some of the edgecases are to test and because most users would not encounter it (which reduces the chance we catch things on beta/nightly).

It appears to me that those arguments are about "downloading to /tmp first, then moving to the Downloads folder". This is not the case that I'm making and I can see the edge cases there. What I am asking, is a dialog that lets me choose to open a file, which as a results downloads the file and opens it, and having the file automatically cleaned up afterwards.

Side note: how does Firefox 97 currently handle the "Always ask where to save files" case? I noticed that it already starts downloading while I'm still selecting a location, supposedly to the default Download folder? Don't the same edge cases apply if the folder that's ultimately chosen not on the same volume? A network disk maybe?

I'm not sure what the add-ons team's thinking about bug 1746880 is, which may help further alleviate the issues you're seeing (ie an add-on could clean up downloads automatically).

But how would that extension know whether to delete the file or not? The important part here is getting the dialog and letting me choose. If an extension can also hook in to ask before (or during, if that's more efficient) the download, that would work for me.

Comment 15

[:Gijs (he/him)]

(In reply to mirh from comment #13)

Can you detail some of those edge cases, hoping they aren't just snaps

I did, in comment 3...

and users moving folders away from beneath a running browser?

The issue is with the downloaded file being moved from one folder to another. Where the initial location is the temp folder, and the final location (e.g. as a result of "ask me where to save files", or just because you're saving a download, not opening it) is either on a different volume, or has different size constraints (like the tmpfs case), or is on a network share - this causes issues. For some examples of how this causes issues, see e.g. bug 1714583, bug 1679675, etc.

(In reply to Timvde from comment #14)

As outlined in comment 3, unfortunately we don't want to reintroduce the tmp option because maintaining it in addition to the new default would cause significant ongoing maintenance costs and likely break periodically because of how hard some of the edgecases are to test and because most users would not encounter it (which reduces the chance we catch things on beta/nightly).

It appears to me that those arguments are about "downloading to /tmp first, then moving to the Downloads folder". This is not the case that I'm making and I can see the edge cases there. What I am asking, is a dialog that lets me choose to open a file, which as a results downloads the file and opens it, and having the file automatically cleaned up afterwards.

There is currently no way to do one without the other. As you noted further down, a network request and response start before we show the dialog - it's the network response that triggers a download in the first place, via the response type (and/or content-disposition: attachment), so we can't "not start" the download until after the dialog shows - it's a chicken/egg kind of situation because of how http works. Moving things back from default downloads folder to temp, or otherwise rearchitecting this, would be an even bigger undertaking. So unfortunately this isn't feasible.

You can still configure filetypes to prompt you for open/save behaviour by setting them to "always ask" in Firefox's settings. You can add new types as/when you download them as described on the support page ( https://support.mozilla.org/en-US/kb/manage-downloads-preferences-using-downloads-menu ), by clicking the "always open similar files" option and then configuring further in settings. Bug 1747343 covers having a "default" mechanism, ie what to do by default for "other files" that you've not configured - the product team has not made a decision there yet.

Automatically deleting the files, without having them stored in the temp folder, is something we won't do outside of private browsing mode, because it's confusing for non-expert users to have some files in their default downloads directory stay, and others disappear when Firefox quits. And again, maintaining this behaviour going forward when it's not the default would be an ongoing maintenance burden. In Firefox 98, bug 1745624 adds a context menu in the downloads panel that lets you easily delete files, which perhaps helps your usecase a bit?

Side note: how does Firefox 97 currently handle the "Always ask where to save files" case? I noticed that it already starts downloading while I'm still selecting a location, supposedly to the default Download folder? Don't the same edge cases apply if the folder that's ultimately chosen not on the same volume? A network disk maybe?

They are much less likely to happen. Before, all Windows users with roaming profiles and default downloads settings would hit the "move from local to network" case and now they do not (because the temp dir is local and the user download dir is not; and now by default we just rename the .part file in the same directory - the "always ask where to save" option is not the default). Before, snap users had issues, and now they don't (or at least not as many; snap/flatpak is... interesting). Before, linux users with an in-RAM temp dir had issues, and now they don't. So we believe the combination of all our changes in this area will make downloads more reliable, and easier to understand for most users. We're sorry that it's a nuisance for you and some other expert users who have invested in the previous workflow, but we don't think there's a cost/benefit-effective way that really alleviates that in a way that is both reliable and maintainable in the longer term.

I'm not sure what the add-ons team's thinking about bug 1746880 is, which may help further alleviate the issues you're seeing (ie an add-on could clean up downloads automatically).

But how would that extension know whether to delete the file or not? The important part here is getting the dialog and letting me choose. If an extension can also hook in to ask before (or during, if that's more efficient) the download, that would work for me.

It would get an event if/when you opened the download from the dialog and/or the downloads panel, and could use that to decide to schedule it for deletion.

If an add-on wanted to, I believe it could already (without bug 1746880 being fixed) do hooking and prompting for each download, if that's what you wanted, but it would need to provide its own UI (ie the webextensions APIs don't provide a way to invoke Firefox's own "what do you want to do with this file" dialog). I don't know that there are enough people who want behaviour like that to warrant an add-on like that, but from a technical perspective I believe it's feasible...

Comment 16

[mirh]

(In reply to :Gijs (he/him) from comment #15)

I did, in comment 3...

And I had already replied to you in comment 10..

The issue is with the downloaded file being moved from one folder to another. Where the initial location is the temp folder, and the final location (e.g. as a result of "ask me where to save files", or just because you're saving a download, not opening it) is either on a different volume, or has different size constraints (like the tmpfs case), or is on a network share - this causes issues. For some examples of how this causes issues, see e.g. bug 1714583, bug 1679675, etc.

Those are some horrific bugs to a level that I couldn't even imagine... But those aren't specific to the download temporary file "behaviour", are they? I mean, bug 1679675 is related to the possible special situation of the temp folder itself, but you could also hit it if the system administrator of some domain decided to set that as the default download folder. (or, duh, private browsing I believe?)
Bug 1714583 instead doesn't even sound related to anything of this tbh.

(In reply to Timvde from comment #14)
We're sorry that it's a nuisance for you and some other expert users who have invested in the previous workflow, but we don't think there's a cost/benefit-effective way that really alleviates that in a way that is both reliable and maintainable in the longer term.

I'm really really trying to paint this analysis without my own needs/benefits outshining everything else.
But I'm struggling to see the cost (the burden, debt, I don't know how else to call it) like *at all*. They all seem bugs that you'd have to eventually solve anyway.

Also (even though it could just be confirmation bias) I feel like there are far more people/nerds pissed off by the loss of a much appreciated and useful feature altogether, than the thing potentially breaking once in a blue moon and then having to patiently fill out a bug report.
If I can explain.

Comment 17

[:Gijs (he/him)]

(In reply to mirh from comment #16)

Bug 1714583 instead doesn't even sound related to anything of this tbh.

I'm sorry that it doesn't sound related to you, but it is. In comment 10 you were sure the downloads implementation must work a certain way because of android, but it doesn't. I wrote some of the patches involved. If you don't think I'm acting in good faith, or competent, then there's no point in me trying to explain. If you're convinced my understanding of the code is wrong and are trying to help me see how I'm wrong, I'm going to need more detail than "doesn't sound like".

I'm really really trying to paint this analysis without my own needs/benefits outshining everything else.
But I'm struggling to see the cost (the burden, debt, I don't know how else to call it) like *at all*. They all seem bugs that you'd have to eventually solve anyway.

It means having to duplicate automated and/or manual tests to test both configurations, and likely a repeating cycle of bugreports specific to this case -> spend a week or two back and forth with the reporter to work out why it's broken for them and not everyone else -> set up a similar situation locally -> diagnose and fix it -> land the fix, which concludes a period users with that configuration have had a broken experience for at least 2, maybe 3 cycles (so 2-3 months), because of the time between shipping a "broken" Firefox, receiving reports, fixing them, and those fixes riding the then-current nightly train to release. Meanwhile, instead of having to adjust their workflow once (ie when there isn't an about:config option or whatever), a [large] subset of those users never get to the "report a bug" and "wait a few months for a fix" stage, instead just deciding Firefox must be broken and switching browsers. That's not ultimately good for us. We're much much tinier than most other browser makers and have to focus our energy where it helps everyone, and maintaining options with high breakage risks that benefit very few users isn't that.

Comment 18

[mirh]

(In reply to :Gijs (he/him) from comment #17)

In comment 10 you were sure the downloads implementation must work a certain way because of android, but it doesn't.

Sure? Must work? I never said anything about the way the thing is on desktop.
I just argued that's the same problem of sandboxing you'd have in android, and therefore it's a problem already solved "technically".

Maybe I'm wrong in considering the two codebases similar enough (and even if they were it's not like it's just one line of code), but it doesn't seem god knows which conundrum to at least figure out.

Meanwhile, instead of having to adjust their workflow once (ie when there isn't an about:config option or whatever),

I understand the notion of "you shouldn't just assume what you are used to do is actually the best and/or right way". But every workaround you provided seems a band-aid conceptually.
A bulk deleting extension, or even a post-hoc "click to delete" button, is quite different mentally from deciding whether you want to keep a file or not concurrently to the decision of downloading it in the first place and then calling it a day.
By no means it's the end of the world, but there's inherently a set of usages you leave out here.

a [large] subset of those users never get to the "report a bug" and "wait a few months for a fix" stage

Like, I'm not sure sure why you think I'm accusing you of being stupid or disingenuous, but it's here that I'm completely lost for meaning.
Why would you need a "large subset" of people to report bugs? Only one guy with enough good will is fine.
And I, for one, was one hours after I installed the beta, and I saw many other people having worried about the nightly in the months before (certainly plenty more would have raised a point too, if they hadn't found this and other issues).

As a very anecdotal matter of fact btw, I swear just almost every comment in the firefox subreddit threads relative to this change were complaining.

We're much much tinier than most other browser makers and have to focus our energy where it helps everyone, and maintaining options with high breakage risks that benefit very few users isn't that.

I know you are quite spread thin, and of course it's not just a matter of *this* one bug alone but the whole class of other "more or less secondary" usecases.
But exactly because I don't feel like you have the premises right (what the "lost benefit" is, and what the "added costs" are), that I'm trying to at least put the record straight.
If you tell me "I understand the intersection of needs that we are now falling short of addressing, but even the most stupidest small extra test could not justify it maintenance wise".. I mean, it's still hard to believe to be really honest, but I couldn't really argue with it.

Comment 19

[:Gijs (he/him)]

(In reply to mirh from comment #18)

a [large] subset of those users never get to the "report a bug" and "wait a few months for a fix" stage

Like, I'm not sure sure why you think I'm accusing you of being stupid or disingenuous, but it's here that I'm completely lost for meaning.
Why would you need a "large subset" of people to report bugs?

Oh, not to get it fixed - but those people leave Firefox and don't come back.

The benefit of an about:config pref or w/e is determined by how many people it benefits, and by how much it does so. That set gets smaller every time it breaks stuff and people (invariably not remembering that they set it) can't figure out how to unbreak it. So I'm arguing that the about:config pref, were we to create and maintain one, would have a very limited benefit. I think the outcome will be better if people adapt their workflow now, to one that we're in a good position to support going forward.

By contrast, the pref we added to avoid opening the downloads panel (in bug 1738372) was a pretty small patch and is unlikely to materially affect maintenance going forward. I don't think either of those things are true for the request in this bug.

But exactly because I don't feel like you have the premises right (what the "lost benefit" is, and what the "added costs" are), that I'm trying to at least put the record straight.
If you tell me "I understand the intersection of needs that we are now falling short of addressing, but even the most stupidest small extra test could not justify it maintenance wise".. I mean, it's still hard to believe to be really honest, but I couldn't really argue with it.

I would probably say something more like "adding the pref and the associated additional testing would substantially increase our tech debt and maintenance burden" - it's much more than "the stupidest small extra test" - but yes. It's clear that we disagree about the premises - about the cost of an option here, as well as the size of the potential benefit of such an option. Based on this conversation, I don't think that difference of opinion can be resolved.

Comment 20

[mirh]

(In reply to :Gijs (he/him) from comment #19)

Oh, not to get it fixed - but those people leave Firefox and don't come back.

The benefit of an about:config pref or w/e is determined by how many people it benefits, and by how much it does so. That set gets smaller every time it breaks stuff and people (invariably not remembering that they set it) can't figure out how to unbreak it.

It gets smaller when people are fed up with it, but AFAICT people are far more pissed off by "purposeful regressions" rather than whatever "accidental bug" that is just the case that could happen with all software. I don't know then if your n-years experience with the community (certainly more than mine) suggest otherwise.

Do you have any telemetry about browser.download.improvements_to_download_panel=false?

I would probably say something more like "adding the pref and the associated additional testing would substantially increase our tech debt and maintenance burden" - it's much more than "the stupidest small extra test" - but yes.

I guess my example was a bit exaggerated, but even though I have really no metrics to imagine the amount of effort involved, I'm still left bewildered that you are reporting so much would be needed for writing test units and yet at the same time problems would be so likely and potentially obnoxious too.

Comment 21

[jan.t.neurer]

Very confused 97.0b6 user here. Trying to understand why it is a good thing that using streams like http://orf-live.ors-shoutcast.at now results in several .m3u files in the download directory.

Comment 22

[VEG]

I use "Open" a lot. The new behavior is really annoying, it just clutters my usually empty downloads directory with temporary files.

Even Microsoft Edge (the default Windows browser) has such setting, and it works as expected, storing a temporary file in the temp directory.

Comment 23

[mooms]

Same here, I'm using "Open" a lot, precisely because I don't want to keep the files, but now the "Downloads" folder (a folder I'm not using, as my downloads are made on an other disk/folders) will be cluttered by a lot of pdf, m3u, video files, useless archives, torrent files, etc...

One more time, it a regression, why Mozilla is thinking ? nobody asked for this backwards change, and saying "Edge/Chrome or whatever is doing the same" is not a good explanation. If I wanted the same behavior, I would use them !

I really don't understand where is the issue with keeping this behavior, it was like that since the beginning, if I open a file, I don't want to keep it, it's that simple !

Comment 24

[mooms]

Can we at least agree that we should be able to choose the folder where Firefox will download the files if we choose to "open" ?
What if we don't use the "Downloads" folder ?

Comment 25

[:Gijs (he/him)]

(In reply to mooms from comment #24)

Can we at least agree that we should be able to choose the folder where Firefox will download the files if we choose to "open" ?
What if we don't use the "Downloads" folder ?

As noted in earlier comments (e.g. comment 7), you can already (still) do that from the regular Firefox settings by changing the default downloads folder.
If you have Firefox set to "always ask me where to save files", switch the radio button, change the folder, then switch the radio button back. No, that's not the clearest UI, and we'll investigate making that more obvious, but this isn't the right bug for that.

Comment 28

[gsp]

Didnt know this was historical that actually goes to stable. V98.0 is unusable at this state... I mean, we still need "Downloads" as the default downloads folder and temp files not going to temp simply create a mess in the downloads folder. Will stick to V97.X for now

Comment 29

[lrdix]

I hope this doesn’t sound rude or aggressive. I am trying to understand your thoughts and to convey my situation.

Recently, after the update to 98.0 I was profoundly annoyed when I found FF to have reset the preference for PDFs to open inside FF. Today, I noticed a lot of PDFs in my ~ (/home/<user>, I am on GNU/Linux, [1]) that I read yesterday. Those where package documentations I opened from CTAN, and I never save those anywhere. So I did a quick test and found that FF saves a file in my ~, when I tell FF to open it with the default PDF viewer. That brought me here.

There are PDFs I only peek into once (e.g. data sheets), there are PDFs I need to read and then save somewhere, there are PDFs I save somewhere right away without opening them, and there are PDFs I don’t know what I’ll do with before reading them. For me, with PDFs, there is only this very general workflow that fits all cases: Have FF ask me what to do, I’ll either open it or save it right away. If I decide to save it after I looked at it, I’ll save it using the viewer’s save dialog, and I’ll save it where it has to go, which never is any download folder. So, a long time ago (way more than a decade!), I have decided to set a browser up to always ask me. As you see, I want that for a very specific reason.

I think I speak for many users when I say settings a user altered shouldn’t be meddled with. That is a really important point, I think: You are a user of some software, and one day the software decides to change something on it’s own, ignoring what you “told” the software to do. Software has no “right” to do that. I think such behaviour annoys the hell out of many users.

What you have achieved is this:

• find a file online
• have FF open it in another app
• work with the file in that app
• decide whether you want to keep the file
• if yes, save it, where it should be saved
• if no, just close the app
• delete a copy of the file in a directory FF picked to use as download folder

Now, we always have to do that last step. Sorry for the wording, but now, FF is spamming a directory with files no one wants. For me as a user, this is not a little thing I have to work around, it’s a major hassle.

In Firefox 98, bug 1745624 adds a context menu in the downloads panel that lets you easily delete files, which perhaps helps your usecase a bit?

No, because opening that panel alone is a big inconvenience (reaching for the mouse, looking for the symbol, moving the pointer to it precisely enough to be able to click it, click it, maybe go through a long list of downloads and look for those I want to delete, starting to make decisions on other files, getting distracted and loosing my nerves because I have to do things that actually are none of my tasks). I hardly ever use that panel. At most, I watch the symbol fill up blue while waiting. Most of the times I do other stuff during the download, or the download is so quick that I don’t have to wait more than a few seconds. Sometimes I open the download list and empty it. Never ever would it occur to me to use that list to delete files. There are file managers for that.

Please understand, I don’t want to attack anyone personally, but I consider myself a power or expert user to a certain degree, and I feel like the situation with FF is being one constant downhill ride in quality for years now. I get quite frustrated with every (other?) major FF upgrade, because features I use suddenly disappear or change. Features that made work easy and efficient. We got all sorts of modernisations, that, from my user point of view, merely broke our ways of using FF. I used Chrome/Chromium for a few things that didn’t work with FF (at work, where I have to use things like Windows, and Skype Web App, and god knows what else). I tried to open a PDF from the web in a PDF viewer when using Chrome a few years ago. I only remember it being a nightmare and one big reason not to use Chrome. Today, I tried to get Chrome to ask me what to do instead of opening it in Chrome. I just don’t have the time and patience to find out if this is even possible.

I find it hard to accept that I have to perform additional actions several times a day, because a decision was made to alter a small but fundamental detail of how FF behaves.

Now, you are concerned that users turn away from FF and don’t come back, when there is a bug for a few months. I understand what you mean, but do you have any data on users actually leaving so quickly, and not coming back, and on users not turning away from FF after a behaviour they got used to changed and couldn’t be reverted? Other browsers sure have bugs to, and maybe there is migration from those to FF. And I think there are a lot of power users being very frustated with FFs development over many years now. Don’t you mind loosing them? They are much more likely to report bugs, I think.

---

Some thoughts on your point of view:

So we believe the combination of all our changes in this area will make downloads more reliable, and easier to understand for most users.

I think it makes downloads only a little bit more reliable (or do you have reliable data on this being a frequently occuring issue?), and as I said, my experience with muggles non-nerds is: They don’t even think about whether they understand downloads or not. For those using FF, there is opening (with app X), saving (in a place they need to choose) and viewing (inside the browser, except they probably are not even aware they are using a “browser” and viewing a file inside it, no kidding). When they open or view, they don’t consider it saving/downloading, because the saving isn’t what they decide to do, it’s what the browser does, and they don’t even see it.

We're sorry that it's a nuisance for you and some other expert users who have invested in the previous workflow, but we don't think there's a cost/benefit-effective way that really alleviates that in a way that is both reliable and maintainable in the longer term.

I understand your point, but I doubt that it’s only some other expert users. I think, there are a lot of users, and I think there are actually a lot of user you wouldn’t call experts, that don’t like the new behaviour. I actually know some, who at the same time answer “I don’t know.” if I ask them “Do you ever use the ask-what-to-do feature when looking for PDFs online?”

It’s not that we have invested a bit in one workflow and now have to invest a bit in a new one that is equally good. It just isn’t. It’s significantly less efficient. One major reason for me to use Linux instead of Windows is efficiency, ergonomics, usability, user-friendliness, whatever the term. Same goes for FF instead of Chrome & Co. Actually, I wouldn’t say I invested in a workflow. I looked at FF and found useful features, looked at Chrome and so on and didn’t.

I can’t estimate the actual cost of maintaining this feature or that one in a software, but, in this case, I doubt the benefit is really as high as you think it is.

---

Some questions on the problem:

(In reply to :Gijs (he/him) from comment #3)

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). (…)

I don’t see why an ordinary user would want to find the location of a file that deliberately was opened with an app like a PDF viewer. I’d rather guess the user isn’t even aware the file was actually first downloaded and then opened. That is what I encountered over many years as someone having to be the admin for family and friends. I don’t think the new behaviour is the most straightforward one to understand for the average joe, as mirh put it. I don’t think it is the better default for less technical users. Are there investigations on this? I would really like to know.

Then there's the fact that it doesn't work for snap/flatpak builds because of permissions issues.

In what situation do you need snaps/flatpaks to be able to access /tmp out of FF?

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.

Installing yet another extension to get back a desired feature or behaviour isn’t satisfying, frankly.

(In reply to :Gijs (he/him) from comment #12)

As outlined in comment 3, unfortunately we don't want to reintroduce the tmp option because maintaining it in addition to the new default would cause significant ongoing maintenance costs and likely break periodically because of how hard some of the edgecases are to test and because most users would not encounter it (which reduces the chance we catch things on beta/nightly).

Am I getting this right: You are introducing a new behaviour, that needs testing, and get rid of an older one, because that needs testing, too, and you cannot do both. The old behaviour could break sometimes, with most people not noticing it. The new behaviour is a major inconvenience for many people many times every day, but still better than the old one? Isn’t it possible to “fix” the old behaviour (check the final destination before starting the download)? Answer:

(In reply to :Gijs (he/him) from comment #15)

There is currently no way to do one without the other. As you noted further down, a network request and response start before we show the dialog - it's the network response that triggers a download in the first place, via the response type (and/or content-disposition: attachment), so we can't "not start" the download until after the dialog shows - it's a chicken/egg kind of situation because of how http works. Moving things back from default downloads folder to temp, or otherwise rearchitecting this, would be an even bigger undertaking. So unfortunately this isn't feasible.

Okay, so you need the response type to choose the corresponding behaviour for that file type (right?). But don’t you then still know it’s a PDF or any other file type before opening the dialog and are therefore able to switch from a download folder to tmp? If the user then says “save” instead of “open” and chooses a folder, why not check the disk space there, before going on, and telling the user to choose differently when it’s not enough? Or am I still not understanding the technical problem?

Side note: how does Firefox 97 currently handle the "Always ask where to save files" case? I noticed that it already starts downloading while I'm still selecting a location, supposedly to the default Download folder? Don't the same edge cases apply if the folder that's ultimately chosen not on the same volume? A network disk maybe?

They are much less likely to happen. Before, all Windows users with roaming profiles and default downloads settings would hit the "move from local to network" case and now they do not (because the temp dir is local and the user download dir is not;

Why would it not be local?

and now by default we just rename the .part file in the same directory - the "always ask where to save" option is not the default).

Do you mean you rename as opposed to having to files (file.name and file.name.part)? What is the difference? Those two files are in the same directory, too. How does it matter, whether that option is the default?

Doesn’t FF remember where to save files even on a file extension or source domain basis? I remember noticing that. Anyway, I still don’t understand why we now have to have a downloads folder when we are not “downloading”.

---

[1] Why is it downloading to ~? Because I don’t use a download folder, and consequently I don’t have one. Really, I hate download folders, I think they are extremely cumbersome. I have to choose an existing directory as download folder to keep FF from creating /home/<user>/Downloads (I don’t like upper case letters in file names, either), even if I set FF up to always ask me where to save downloads. So I chose ~.

Comment 30

[jan.t.neurer]

Is circle referencing closed issues and tagging valid comments truly the best way to deal with user input?

For reference: Setting "browser.download.improvements_to_download_panel" to "false" in about:config mitigates the functional degradation.

Comment 31

[lrdix]

I thought not using a downloads folder made me a singularity, but behold: https://lwn.net/Articles/887506/

Comment 32

[lrdix]

Oh, that is what you mean by tagging valid comments. I actually overlooked all advocacy-ed comments.

Comment 33

[:Gijs (he/him)]

(In reply to jan.t.neurer from comment #30)

For reference: Setting "browser.download.improvements_to_download_panel" to "false" in about:config mitigates the functional degradation.

This is a rollout preference and it will be removed in future, just like the proton prefs last year. It is actively harmful to tell people to change it, as they will just have the same problem again when the pref ceases to do anything (and will then be confused and/or angry again, because it still shows up in about:config but fails to help them etc. etc.).

(In reply to lrdix from comment #29)

I hope this doesn’t sound rude or aggressive. I am trying to understand your thoughts and to convey my situation.

Well, to quote from your muggle reference, "sadly, accidental rudeness occurs alarmingly often".

Although I of course disagree that we're "circle referencing" issues, there are a number of interlocking issues here and I don't think it's useful to keep repeating things that have already been said. I'll try to address some of the points you raised but I've snipped pretty liberally because frankly, I have code reviews and patches to deal with.

I think I speak for many users when I say settings a user altered shouldn’t be meddled with. That is a really important point, I think: You are a user of some software, and one day the software decides to change something on it’s own, ignoring what you “told” the software to do. Software has no “right” to do that. I think such behaviour annoys the hell out of many users.

In pre-release, we initially did what you suggested: we asked, even for opened files, where users wanted the file saved. That also made people very upset (more interruptions!), so we changed it. You can change which folder is used, so you can change it back to (a chown'd subfolder of) the tmp folder if you so choose. But given the choice between overwriting the default download folder for users from a folder of their choice to such a tmp folder (ie meddling with their settings and annoying them) and leaving that preference in place, but starting to use it for opened files even for users with "always ask" set, we picked the latter.

Although I understand that you perceive it that way, I strongly disagree that "meddling with settings" is a reasonable summary of that process.

I find it hard to accept that I have to perform additional actions several times a day, because a decision was made to alter a small but fundamental detail of how FF behaves.

Similarly, I can point you to countless comments from users like you complaining about bugs being unfixed so long that the bug is old enough to drink in various jurisdictions. We finally fixed a 14-year old bug, the most duplicated Firefox frontend bug, and I'm spending my Tuesday evenings trying to explain that to people upset about it. Well, it's a novel experience, I'll say that. Actually, no, that's a lie, people complain no matter what we do, so that's not particularly novel. With a userbase as large as ours there is no way to do anything that doesn't annoy at least 0.001% of users, which is still enough to turn my mailbox into a very sad affair.

It’s not that we have invested a bit in one workflow and now have to invest a bit in a new one that is equally good. It just isn’t.

It just isn't for you. And that sucks, and I get it, I really do, but please stop biting my head off over it, it won't help.

I can’t estimate the actual cost of maintaining this feature or that one in a software, but, in this case, I doubt the benefit is really as high as you think it is.

It turns out telemetry shows the number of people opening their downloads is up substantially from before 98 (ie by the millions), which basically indicates that just making the location of the downloads panel more obvious (and using it to replace the old confusing "what do you want to do with this file" dialog) is making a positive impact on people's lives. That's the majority of the userbase that we're supporting, and so that (ie people who, for instance, struggled to find their downloads in Firefox's UI) is who the changes are catered towards. I'm sorry this makes things worse for you, but the data suggests you're in a relatively small minority.

Then there's the fact that it doesn't work for snap/flatpak builds because of permissions issues.

In what situation do you need snaps/flatpaks to be able to access /tmp out of FF?

snaps/flatpaks of Firefox need to put downloaded files somewhere [where other apps can read them].

(In reply to :Gijs (he/him) from comment #12)

As outlined in comment 3, unfortunately we don't want to reintroduce the tmp option because maintaining it in addition to the new default would cause significant ongoing maintenance costs and likely break periodically because of how hard some of the edgecases are to test and because most users would not encounter it (which reduces the chance we catch things on beta/nightly).

Am I getting this right: You are introducing a new behaviour, that needs testing, and get rid of an older one, because that needs testing, too, and you cannot do both. The old behaviour could break sometimes, with most people not noticing it. The new behaviour is a major inconvenience for many people many times every day, but still better than the old one?

Your use of "most" and "many" here unfortunately does not match our userbase at all.

Okay, so you need the response type to choose the corresponding behaviour for that file type (right?). But don’t you then still know it’s a PDF or any other file type before opening the dialog and are therefore able to switch from a download folder to tmp? If the user then says “save” instead of “open” and chooses a folder, why not check the disk space there, before going on, and telling the user to choose differently when it’s not enough? Or am I still not understanding the technical problem?

While the dialog is up, the bytes being downloaded in the background need to go somewhere. In your suggestion that would be tmp. If tmp runs out of space before you pick a location and we move the file, the download fails. Plus we would have to test that and the case where the user-chosen location doesn't have enough space in automated tests, which is difficult to do cross-platform (maybe quotas can help, but the internal errors we'd get for that vs actually-no-space-on-the-volume are probably different, so it wouldn't be a "real" test). Then there is the issue that we don't actually know how much space we'll need - the server's Content-Length headers are too often missing or complete fabrications.

If we just save the file to a directory more likely to be on the same drive/volume (or even the plausible final destination of the file, if saved) then most of this problem goes away. It continues to be real for people who pick "always ask me where to save files", but that is a minority.

Before, all Windows users with roaming profiles and default downloads settings would hit the "move from local to network" case and now they do not (because the temp dir is local and the user download dir is not;

Why would it not be local?

Sorry, I wrote "roaming profile" and meant "Windows user profile [or default download directory] on a network volume". Yes, people do this (recent instance: bug 1758635).

Comment 34

[lrdix]

(In reply to jan.t.neurer from comment #30)

For reference: Setting "browser.download.improvements_to_download_panel" to "false" in about:config mitigates the functional degradation.

This is a rollout preference and it will be removed in future, just like the proton prefs last year. It is actively harmful to tell people to change it, as they will just have the same problem again when the pref ceases to do anything (and will then be confused and/or angry again, because it still shows up in about:config but fails to help them etc. etc.).

Why does it still show up, when it isn’t functional anymore? If it wasn’t, users would see it’s gone and be less confused.

(In reply to lrdix from comment #29)

I hope this doesn’t sound rude or aggressive. I am trying to understand your thoughts and to convey my situation.

Well, to quote from your muggle reference, "sadly, accidental rudeness occurs alarmingly often".

I know that it can occur accidentally in situations like the one here, as there is no non-verbal communication, which is why I wrote what you quoted above. If some of what I have written sounds rude to you, please accept my apologies and point me to where that happened.

Although I of course disagree that we're "circle referencing" issues, there are a number of interlocking issues here and I don't think it's useful to keep repeating things that have already been said. I'll try to address some of the points you raised

It wasn’t me who said we were circle referencing issues.

In pre-release, we initially did what you suggested: we asked, even for opened files, where users wanted the file saved. That also made people very upset (more interruptions!), so we changed it. You can change which folder is used, so you can change it back to (a chown'd subfolder of) the tmp folder if you so choose. But given the choice between overwriting the default download folder for users from a folder of their choice to such a tmp folder (ie meddling with their settings and annoying them) and leaving that preference in place, but starting to use it for opened files even for users with "always ask" set, we picked the latter.

Here, I don’t understand what you mean. When I want FF to open a file, I don’t want FF to save that file in the first place. I’m not using a download folder, but I always was aware of FF using a tmp directory, which I think it should still do. Giving me the option to change the download folder doesn’t help at all. See https://bugzilla.mozilla.org/show_bug.cgi?id=1738916#c19

Although I understand that you perceive it that way, I strongly disagree that "meddling with settings" is a reasonable summary of that process.

I don’t think you understand what I mean. Reverting from asking the user what to do with a file to opening it inside FF, with the user not knowing why that happens, because before that change FF was still using tmp, is meddling with a setting the user configured quite well-thought-out. How is the user supposed to know that at the same time you reset that setting you decided not to use tmp anymore, which makes the reset necessary in the first place?

It’s not that we have invested a bit in one workflow and now have to invest a bit in a new one that is equally good. It just isn’t.

It just isn't for you. And that sucks, and I get it, I really do, but please stop biting my head off over it, it won't help.

For me and many others. I’m pretty sure I’m not the only one, just by looking around me a bit (here, blogs, reddit, …). Apart from that: How can the new workflow be as good as the old one objectively, impartially, when it is more work?

It turns out telemetry shows the number of people opening their downloads is up substantially from before 98 (ie by the millions), which basically indicates that just making the location of the downloads panel more obvious (and using it to replace the old confusing "what do you want to do with this file" dialog) is making a positive impact on people's lives.

Well, the panel is opening automatically now, if I remember correctly. Another explanation could be that people are looking into the download history because they want to figure out if they accidentally downloaded a file instead of opening it. Then, if you are using the panel as a replacement for a dialog, again it has to get opened more often then before.

In my FF, the location of that panel isn’t any more obvious than before 98. Everything is looking still the same.

There is simply nothing confusing about the old dialog.

That's the majority of the userbase that we're supporting, and so that (ie people who, for instance, struggled to find their downloads in Firefox's UI) is who the changes are catered towards. I'm sorry this makes things worse for you, but the data suggests you're in a relatively small minority.

snaps/flatpaks of Firefox need to put downloaded files somewhere [where other apps can read them].

Ah okay, you mean, when someone installs FF via Snap or Flatpak. I was thinking about FF dealing with Snaps or Flatpaks. So, when FF has been installed that way, it is being run with different permissions? Interesting. One more reason not to like Flatpak and Snap. Which doesn’t solve any problem of course, I know.

(In reply to :Gijs (he/him) from comment #12)

As outlined in comment 3, unfortunately we don't want to reintroduce the tmp option because maintaining it in addition to the new default would cause significant ongoing maintenance costs and likely break periodically because of how hard some of the edgecases are to test and because most users would not encounter it (which reduces the chance we catch things on beta/nightly).

Am I getting this right: You are introducing a new behaviour, that needs testing, and get rid of an older one, because that needs testing, too, and you cannot do both. The old behaviour could break sometimes, with most people not noticing it. The new behaviour is a major inconvenience for many people many times every day, but still better than the old one?

Your use of "most" and "many" here unfortunately does not match our userbase at all.

No? You used the word “most” the same way. Regarding the word “many”:

there is no way to do anything that doesn't annoy at least 0.001% of users, which is still enough to turn my mailbox into a very sad affair

While the dialog is up, the bytes being downloaded in the background need to go somewhere. In your suggestion that would be tmp. If tmp runs out of space before you pick a location and we move the file, the download fails. Plus we would have to test that and the case where the user-chosen location doesn't have enough space in automated tests, which is difficult to do cross-platform (maybe quotas can help, but the internal errors we'd get for that vs actually-no-space-on-the-volume are probably different, so it wouldn't be a "real" test). Then there is the issue that we don't actually know how much space we'll need - the server's Content-Length headers are too often missing or complete fabrications.

I thought you were saying the space problem comes up, when it is the final destination not having enough space, not tmp. Anyway, none of what you said sounds like not using tmp solves the problem. Either way, checking for available space doesn’t help, if the server doesn’t tell you how much you need (I forgot that problem). But than, running out of space can happen with 98’s behaviour, too. What did you gain?

If we just save the file to a directory more likely to be on the same drive/volume (or even the plausible final destination of the file, if saved) then most of this problem goes away.

I’d rather say it is more likely not to happen, but it still can. What did you gain?

It continues to be real for people who pick "always ask me where to save files", but that is a minority.

You mean, the problem is only real for users picking “always ask where to save” over having a default downloads folder? I disagree hard. Running out of space can always happen.

Again, nothing of what I write I write with a tone of aggression in mind. I am sure what you do is you trying to make FF better for as many users as possible. But I don’t see any downsides for users by FF using tmp. Same goes for the old dialog. What telemetry is showing you, that most people find it confusing? I have the feeling, that Mozilla is making FF maybe a tiny little bit less compatible for many normal users, who hardly notice difference, by making FF much less convenient for expert users, who may be the minority but still in a really large number. And they like FF, and wish for it to stay a cool piece of software. Just look how much time they (we) invest reaching out for you guys.

Comment 35

[lrdix]

Before, all Windows users with roaming profiles and default downloads settings would hit the "move from local to network" case and now they do not (because the temp dir is local and the user download dir is not;

Why would it not be local?

Sorry, I wrote "roaming profile" and meant "Windows user profile [or default download directory] on a network volume". Yes, people do this (recent instance: bug 1758635).

I don’t see any of both being on a network volume in that instance. On the other hand, the university department where I studied had computers for students, setup in a big room, running OpenSuse. The home directories were not local. The folders being on a network volume wouldn’t strike me as unusual.

Comment 36

[janiszw]

Hi :Gijs,

It took me some time to find this bug and email thread, as I could not understand whether the missing prompt is related to recent FF updates or I just changed some preference accidentally. Now I see, it's just behavior that changed in 97+.

Just to let you know that I fully support Irdix and mirh, that something that was working well, was broken at least from my (end user) point of view. Perhaps as you mentioned earlier I'm in a minority of all users, but that's my opinion. I guess there are more users hit by that problem, but they just didn't find that email thread or didn't bother to create bugzilla account.

I understand that you had your reasons to change the behavior, but I just can't get why you're saying that you cannot preserve old behavior of keeping files in a temporary folder. Unless I am mistaken, if I set MIME preference for some type of file to "Always ask", and I'll choose to open downloaded file by an app from a pick list, that file will still be downloaded to the temporary folder, as it was before that change has been implemented.

As of now, I've updated all my MIME preferences but I am missing an option to choose an action for unknown MIME types. So far setting "browser.download.improvements_to_download_panel" works for me. I know it will be removed in the future, but I hope that https://bugzilla.mozilla.org/show_bug.cgi?id=1747343#c6 will be implemented before that happen.

I don't expect any response for my post. Just wanted to say that there are more than couple of users who were hit by that problem caused by recent FF updates.

Thanks for your commitment to this project. Firefox is the best browser thanks to you and other contributors.

I wish you all the best!

Comment 37

[Dalacor]

I would like to add my 2 cents to this. There are four separate issues that I (or my clients) are seeing with the latest upgrades.

1. When I am viewing Pdf's invoices in my Accounting program, it is now downloading a copy of the pdf as well. I don't need a download of the invoices already stored in my accounting program which is web based obviously. On my computer, even with (always ask enabled), I keep getting a downloaded copy as well.

2. I now have clients contacting me saying that all their pdf's download by default. So I now have to tell everyone (or script it) how to reset it so that pdf's are set back to (always ask) which is necessary because sometimes we want to save a pdf document somewhere, but in many cases we want to open the pdf and just view it.

3. The single biggest frustration is that on some Firefox 98/98.01 versions, I go into settings and find the application area and there is no entry for pdf's. So basically for clients who either want to set to (always ask) or to always open with - they have no way to change this setting - so everything is now downloading to the downloads folder all the time. So it appears the only way to fix this is to script this!

4. My clients have their documents, music, pictures, videos etc redirected to the server so that all data is saved on the server. I have allowed the downloads folder to stay in the location, but always have firefox ask where to save downloaded files to force users to save to the correct folder locations on the server. For the occasions when users want to save a pdf but not necessarily to keep, we have the downloads folder. In that instance the downloads folder is useful for that. Now every pdf that is opened in firefox - assuming the user still has the option to change the default back to always ask or always open with - is automatically saved in the downloads folder. Do you have any idea how many documents are temporarily stored in downloads by people who only want the files for a short while. In addition, confidential documents may potentially end up being stored in the downloads folder instead of only in secure areas. So Firefox is now creating loads more files in the downloads folder in addition to the ones that users already save there making it hard to find anything.

You have conflated the downloads folder with the temporary files folder and you have made it impossible to use websites like accounting websites and many other websites where you just want to view pdf documents - you don't want a copy of the document in the downloads as well.

Can you please urgently fix this issue so that the Firefox has the Always ask, always open with and always save options back in Firefox as it was in previous versions. You cannot have a situation where every pdf document you open is saved to the downloads folder. Vast majority of pdf documents our users don't want a copy of as we work in education where educational websites may have pdf's meant to be viewed not saved. In my particular case - and I suspect for other users, I want to have always ask for pdf's because sometimes I want to save a copy of the pdf, but most of the time I just want to open it.

I understand that you made the changes to saving in the downloads folder due to issues and bugs with using the temp files folder. But using the downloads folder for this is not going to work. Secondly, that issue does not appear to have anything to do with the fact that for many users, they can no longer open a pdf as their no pdf setting in application. This has to be restored. I would estimate that only 1 in 10 (if that) pdf's that I view online are ones that need to be saved.

I am happy for you to make Firefox easier for non IT people to use. However, I don't think that this is what has been achieved. These people are now saving everything to their downloads folder - which is the one folder that is very rarely if ever backed up. In addition, especially for pdf's most of the time people only need to view the pdf not save it.

Thank you

Comment 38

[Dalacor]

Forgot to mention that we default to making Firefox open with Pdf Xchange Editor, not using the builtin browser pdf viewer. The reason is twofold. Users got very confused between the two printers (one within the pdf viewer view) and the Firefox Printer - as the print output is different depending on which one you use. In addition, it makes everything consistent if all pdf documents are opened in the same program whether in browser or from windows file explorer.

Comment 39

[:Gijs (he/him)]

(In reply to lrdix from comment #34)

I know that it can occur accidentally in situations like the one here, as there is no non-verbal communication, which is why I wrote what you quoted above. If some of what I have written sounds rude to you, please accept my apologies and point me to where that happened.

Broadly speaking, what is happening at this point, with your and other folks' comments, is that they question the veracity, justification, motivation, or competence behind decisions or statements made by me or other folks. Case in point:

(In reply to lrdix from comment #34)

Why does [the pref] still show up, when it isn’t functional anymore? If it wasn’t, users would see it’s gone and be less confused.

Now, obviously I can give you a technical answer to this question. The short version is: Firefox saves all user preferences that differ from the default set of preferences (either preferences that don't exist at all in the default set, or preferences that have a different value) in prefs.js. So once you change the pref value in question from true to false, it gets saved in your profile, and it will stay there (and thus show up in about:config), even when the pref then stops being supported inside Firefox. We are not about to overhaul the ~25 year old preference infrastructure of gecko and how it stores this stuff to deal with this specific problem. "Trivial" solutions like removing the user-stored preference from the profile once the pref is removed from Firefox have downsides for users who force downgrades (or people who remember they set the pref, go looking for it, and then complain that we "meddled with user settings" by deleting the now non-functional preference), and will just lead to a different set of user complaints.

Either way, this wasn't even a particularly important point of what I said; the main point is that the pref is going to stop working, and "smoothing over" the change in 98 by telling people to flip the rollout pref will just re-incur the same cost a second time when that pref stops working. The presence or otherwise of the changed pref value in about:config is just fuel on that fire - if we "fixed" it somehow by avoiding the pref showing up in about:config, the root problem remains.

But broadly: why couldn't you just take my word for it? Same thing with the snap/flatpak issue. I described the issue, other folks who, like you, disagree with our decision already acknowledged it was real (cf. comment 6)... do you think I'm just making stuff up?

And this is what is frustrating and tiring: every time we change something, we end up with some people complaining about that change, who think that we are either lying, or incompetent, or could "just" make some adjustments to suit them (because how hard could it possibly be to make the millions-of-lines-of-code, operating-system-level-complexity tool do what they want, "just as an option"?), or have missed some crucial bit of workflow for some subset of users, usually complete with some comments about marketshare and how "Firefox has been going downhill for N years/months", "I hated this other thing you did already and now this", etc. etc. And so 4+ months and 30-odd comments after this bug was filed, we're still explaining the same things that we explained from the beginning. Maybe "rude" isn't the most precise word for this - but certainly it isn't constructive, and isn't going to help make Firefox a better product.

Sure, sometimes there are things we overlooked; nobody is perfect. In bug 1756980, people have just in the last 24h identified that how we handle open-inside-Firefox for PDF links that have both download=filename and target=_blank attributes is suboptimal. And that's useful and we'll try and fix that.

But this bug, and the debate about the use of /tmp feels endless and unproductive. We've made a decision not to provide an option to use /tmp and automatically delete files because we feel the risk of user dataloss outweighs the downside for users who find this creates clutter and have to delete files manually and/or with a third-party solution, with the added factor that adding an option for this and supporting it is likely to lead to brokenness which would add further frustration for exactly those users who think an option is going to help them. And when this issue was initially raised, we doublechecked our assumptions (comment #3):

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?

Now we're 4+ months on, and I'm not hearing new reasons, just more complaints about the same reasons. And that's why other folks are tagging comments as advocacy or whatever, because there's no new information, just repeated questioning of the decision that was made.

(I wrote some of this this morning and I see new comments have appeared since, so I'll reply to those next.)

Comment 40

[:Gijs (he/him)]

(In reply to janiszw from comment #36)

I understand that you had your reasons to change the behavior, but I just can't get why you're saying that you cannot preserve old behavior of keeping files in a temporary folder. Unless I am mistaken, if I set MIME preference for some type of file to "Always ask", and I'll choose to open downloaded file by an app from a pick list, that file will still be downloaded to the temporary folder, as it was before that change has been implemented.

It's downloaded to the default downloads folder (which you can configure to be the temp folder if you want) - but it won't get automatically deleted anymore, so it's not exactly the same.

As of now, I've updated all my MIME preferences but I am missing an option to choose an action for unknown MIME types. So far setting "browser.download.improvements_to_download_panel" works for me. I know it will be removed in the future, but I hope that https://bugzilla.mozilla.org/show_bug.cgi?id=1747343#c6 will be implemented before that happen.

At this point that seems likely to happen, though if the past 2 years in the world gestures vaguely around at everything have taught me anything, it's that reading the tea leaves of the future is an uncertain business.

---

(In reply to Dalacor from comment #37)

1. When I am viewing Pdf's invoices in my Accounting program, it is now downloading a copy of the pdf as well. I don't need a download of the invoices already stored in my accounting program which is web based obviously. On my computer, even with (always ask enabled), I keep getting a downloaded copy as well.

If you pick "open with Firefox" as the default action for PDFs, we'll open them directly from the internet in almost all cases (there are some edgecases to be worked out, cf. bug 1742648), without storing anything on disk in the first place. You can then still save them to disk if that's what you want, by using the save button on the PDF viewer toolbar.

2. I now have clients contacting me saying that all their pdf's download by default.

So to be clear, we tried not to change the default action for PDFs. We changed it for most other mimetypes, but not PDFs (nor any other filetypes set to "open in Firefox" by default). If you're seeing something else, please file a separate bug (though whether at this point, after the defaults have changed in a user profile, we can retrospectively fix it without changing defaults for anyone else remains to be seen - but we'd need a bunch more details).

So I now have to tell everyone (or script it) how to reset it so that pdf's are set back to (always ask) which is necessary because sometimes we want to save a pdf document somewhere, but in many cases we want to open the pdf and just view it.

Yeah, that sucks. I will repeat my recommendation for using the "open in Firefox" option to just view the PDF.

3. The single biggest frustration is that on some Firefox 98/98.01 versions, I go into settings and find the application area and there is no entry for pdf's.

This should be impossible for PDFs, unless you literally have an external tool messing with files in the user's Firefox profile folder. There is an entry there for PDFs because we write one out. It'd be useful to file a separate bug for this with more details (are you using enterprise policy to disable the builtin PDF viewer, perhaps?) - like (2), this seems unrelated to whether we use tmp and/or autodelete files, so it's not really directly related to this bug, but to other changes to downloads that we enabled in 98.

So basically for clients who either want to set to (always ask) or to always open with - they have no way to change this setting

They do, right click any PDF in the downloads panel and select "always open similar files" to always open them. That will cause the option for that filetype to show up in the Firefox settings. FWIW, this (along with other questions we anticipated) is documented on our support site and that document was linked from the release notes...

Do you have any idea how many documents are temporarily stored in downloads by people who only want the files for a short while.

Well, based on what you're saying, I'm guessing a lot? I would recommend you tell them to change the default downloads folder (or use enterprise policy to do so, which it sounds like you might already be using given "I have allowed the downloads folder to stay in the location" which suggests you have control over this).

You have conflated the downloads folder with the temporary files folder

For downloads in Firefox, yes.

and you have made it impossible to use websites like accounting websites and many other websites where you just want to view pdf documents - you don't want a copy of the document in the downloads as well.

I don't think this separate part is fair, though.

Yes, you and your users will need to adapt your workflows to this change. I'm sorry about that. I don't have a lot of insight into your software and environment - it sounds like there are a lot of external constraints around which PDF viewer is in use and what printer is in use and what folders are/aren't allowed to accumulate files or are backed up. It's possible that Firefox is not the right tool for your usecase. It's possible that you can make it work for your usecase with the right combination of settings, but I don't think I'm in a position to help. If you need more support, you can try https://support.mozilla.org/ .

Can you please urgently fix this issue so that the Firefox has the Always ask, always open with and always save options back in Firefox as it was in previous versions.

The options are still there, but some of them work differently. This bug is already marked wontfix, and I don't see that changing. Sorry.

(In reply to Dalacor from comment #38)

Forgot to mention that we default to making Firefox open with Pdf Xchange Editor, not using the builtin browser pdf viewer. The reason is twofold. Users got very confused between the two printers (one within the pdf viewer view) and the Firefox Printer - as the print output is different depending on which one you use.

This seems like an orthogonal issue that might be worth filing a bug about. With a very quick check I can't see the issue you're describing (we made some printing improvements in recent-ish versions of Firefox, too, perhaps those helped?).

In addition, it makes everything consistent if all pdf documents are opened in the same program whether in browser or from windows file explorer.

I can see the appeal - as a long shot, you can set Firefox as the Windows PDF viewer as well, but I could see that might not be what you want.

Comment 41

[MM1997]

I see a lot of technical discussions here, but as a non-technical but long-time firefox user and fan, I need an answer to a simple question, just to clarify things.

Before v98, I could achieve a simple download flow which I enjoyed for many years:

When downloading a file (no matter what type of file), first I could decide if I want to open it or save it.

• When "open it", it was saved in my temporary files folder and then opened with default app.
• When "save it", it was saved in my default downloads directory and nothing else happened after that.

So now I have a simple question - is there a way to achieve THE SAME behavior using new download system and not configuring it through about:config? To be honest, i need a simple Yes or No answer and I would know if I need to start looking for another browser.

Comment 42

[Dalacor]

I have created a new bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1759984

This will raise the issue of the bug where the pdf settings in application have disappeared after upgrading to Firefox 98. I assume based on the suggestion here that the issue is because we disabled the Firefox pdf viewer in order to make Firefox default to always ask so it either downloads or opens up with Pdf Xchange editor.

I have also come up with suggestions for improving Firefox 98 as I do understand the logic behind moving the Firefox view files from the temp folder to the downloads folder. I am hopeful that my suggestions would achieve your objectives as well as addressing user concerns about the downloads folder becoming the new temp files folder, in addition to the loss of choice of always ask - open or download.

Thanks

Comment 43

[lrdix]

(In reply to :Gijs (he/him) from comment #39)

(In reply to lrdix from comment #34)

I know that it can occur accidentally in situations like the one here, as there is no non-verbal communication, which is why I wrote what you quoted above. If some of what I have written sounds rude to you, please accept my apologies and point me to where that happened.

Broadly speaking, what is happening at this point, with your and other folks' comments, is that they question the veracity, justification, motivation, or competence behind decisions or statements made by me or other folks. Case in point:

(In reply to lrdix from comment #34)

Why does [the pref] still show up, when it isn’t functional anymore? If it wasn’t, users would see it’s gone and be less confused.

Now, obviously I can give you a technical answer to this question. (…) "Trivial" solutions like removing the user-stored preference from the profile once the pref is removed from Firefox have downsides for users who force downgrades (or people who remember they set the pref, go looking for it, and then complain that we "meddled with user settings" by deleting the now non-functional preference), and will just lead to a different set of user complaints.

I wasn’t aware that you are taking downgrades into account. With that, I wouldn’t be removing the non-functional pref either. Then, maybe marking it as invalid or something could avoid confusion. Anyway, that’s off-topic.

I am not questioning your veracity, justification, motivation (making FF better for the majority of users), or competence behind decisions or statements. At least, not from the start. I think, I have made that sufficiently clear.

But yes, I am questioning a few things you said, things that make no sense to me. I can’t see anything wrong with that. You haven’t answered one particular question that I have asked several times, I think (see my link above, to the other bug, too):

Why do you think people are/were being confused with a PDF being in tmp, where they cannot find it, when they didn’t want to download it in the first place? Why would they be looking for that file? I have never seen anyone do this. Only people who know of tmp, and they are usual successful, not confused.

One more thought on this: You argue people can deletes file using the download panel. Well, why don’t you think they could find a file there they just opened and wouldn’t be looking for in tmp, too? If you now say they wouldn’t be looking in the downloads panel, because they didn’t intend to download it, I say: They wouldn’t use the panel to delete it, because they didn’t even notice the file being downloaded. There seems to be a general lack of logic of how FF handles things now.

You try to be very stringent about your technical reasons, but at the same time you suggest to use tmp as downloads folder. To me, that seems to be a dirty hack, to say the least.

So, yes, I question – once again – the decision of not using tmp files anymore. What you have done is this: You are still giving users the choice of opening a PDF in an external viewer, but contrary to before 98 you now download the file and tell an external viewer where it is and to open it. I think, that is what Chrome does. And I get it, that is the idea of how to avoid using tmp. But what you seem to be refusing to understand: The downloading isn’t part of what the user asks for. This is why it was being hidden in tmp for decades. The way Chrome (and now FF) handles this, is (part of, but a big part) why Chrome sucks and why I don’t use it.

I believe you, when you say, that using tmp has issues. But the issues you explained, as far as I understand, apply to a downloads folder all the same. You didn’t go into my comments regarding this, too.

If you stick with not using tmp, then consequently stop telling users you were opening a file. Just download it, without the option of opening it in an external viewer, or tell people that you are about to download a file they don’t want to download, and give them the option to open it inside FF instead:

• Save file to …
• Open file in Firefox
• Download file and open with <dropdown list>

That would be less confusing, but still be a step backwards in terms of UX.

We are not about to overhaul the ~25 year old preference infrastructure of gecko and how it stores this stuff to deal with this specific problem.

But you did overhaul the way FF handles files after decades.

But broadly: why couldn't you just take my word for it? Same thing with the snap/flatpak issue. I described the issue, other folks who, like you, disagree with our decision already acknowledged it was real (cf. comment 6)... do you think I'm just making stuff up?

No, as I said above. And regarding snap/flatpak I never questioned anything. Maybe you just got wrong what I wrote about that.

And this is what is frustrating and tiring: every time we change something, we end up with some people complaining about that change, who think that we are either lying, or incompetent, or could "just" make some adjustments to suit them (because how hard could it possibly be to make the millions-of-lines-of-code, operating-system-level-complexity tool do what they want, "just as an option"?), or have missed some crucial bit of workflow for some subset of users, usually complete with some comments about marketshare and how "Firefox has been going downhill for N years/months", "I hated this other thing you did already and now this", etc. etc. And so 4+ months and 30-odd comments after this bug was filed, we're still explaining the same things that we explained from the beginning. Maybe "rude" isn't the most precise word for this - but certainly it isn't constructive, and isn't going to help make Firefox a better product.

Well, for some years now, everytime there is a new major version of FF, something isn’t working anymore and we have to come up with new workflows. See, it’s very frustrating and tiring for users, when a piece of software, that was working just fine for many years, loses one very useful feature after another. That can’t be so hard to understand.

And every time the developers justify that with reasons that are actually hard to understand. It is a long list. Every time you try to reason with developers they actually have a strong tendency to produce arguments that seem very cabalistic, and whatever objective reason in favor of user-friendliness you come up with, they won’t accept it. One strong example is the compact view in Nautilus (Gnome 3): “It’s counter-intuitive when things scroll horizontally when you turn the mouse wheel vertically, that’s confusing users. Wontfix.” That’s got nothing to do with FF, sure, but there are a lot of examples concerning FF, too.

Obviously, this is a long story of mutual incomprehension, and it doesn’t look like things are going to change.

But this bug, and the debate about the use of /tmp feels endless and unproductive. We've made a decision not to provide an option to use /tmp and automatically delete files because we feel the risk of user dataloss outweighs the downside for users who find this creates clutter and have to delete files manually and/or with a third-party solution, with the added factor that adding an option for this and supporting it is likely to lead to brokenness which would add further frustration for exactly those users who think an option is going to help them. And when this issue was initially raised, we doublechecked our assumptions (comment #3):

Well, that is what you feel, and we got it. We told you what we feel. From everything I experienced using computers and FF, and from everything you told us here, to me, your fear of dataloss seems to be considerably bigger than the actual problem.

Maybe you are right and the decision not to use tmp anymore is the best there is. But at the moment, your answers rather suggest otherwise.

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?

Now we're 4+ months on, and I'm not hearing new reasons, just more complaints about the same reasons. And that's why other folks are tagging comments as advocacy or whatever, because there's no new information, just repeated questioning of the decision that was made.

Aren’t those reasons enough? What mismatch are you seeing here? You should be getting an idea of how many people there actually are, that are frustrated because of that change.

Comment 44

[Peter F [:peterfab]]

(In reply to MM1997 from comment #41)

So now I have a simple question - is there a way to achieve THE SAME behavior using new download system and not configuring it through about:config?

I don't have a solution which is entirely about:config-less, but here is what I've done and am satisfied with:

1. Select the "Save files to" directory to be your desired temp location, then switch the radio button to "Always ask you where to save files" (as described in Comment 25). This causes all files to be downloaded here before taking any other action.
2. Switch all file types to "Always ask". If one is not in the list, then if/until Bug 1747343 is resolved, you'll need to download a file of that type, then in the downloads panel select "Always Open Similar Files" (Comment 7). This causes the dialog asking what to do with a file to come up each time one is downloaded.
3. Make sure that the about:config pref "browser.download.folderList" is set to 2. This has Firefox default to the last used directory in the download location picker (which we enabled in step 1), instead of defaulting to the directory set in the "Save files to" setting.
4. Download a file and save it to your desired non-temp downloads folder.

These steps should result in the following pref settings:
browser.download.dir: temp directory
browser.download.folderList: 2
browser.download.lastDir: non-temp directory
browser.download.useDownloadDir: false

I'm not entirely sure about step 4, given this quote from Comment 29:

Doesn’t FF remember where to save files even on a file extension or source domain basis? I remember noticing that. Anyway, I still don’t understand why we now have to have a downloads folder when we are not “downloading”.
This behavior sounds familiar to me as well, but so far, everything has defaulted to my desired download folder when I select the "Save" option. If it turns out to be a problem, maybe pin your downloads folder in the folder picker?

The only real annoyance with this method over the previous behavior is that you need to pick the location every time - I had it this way before, but I see how it could be bothersome to somebody else.

Comment 45

[jan.t.neurer]

(In reply to :Gijs (he/him) from comment #33)

This is a rollout preference and it will be removed in future, just like the proton prefs last year. It is actively harmful to tell people to change it, as they will just have the same problem again when the pref ceases to do anything (and will then be confused and/or angry again, because it still shows up in about:config but fails to help them etc. etc.).

You are right, i could have been more precise about its half-life. Though i'm not sure if posting a "mitigation" on a bug tracker is considered to be "actively harmful". A doctor lighting a cigarette at an incubator, yes. But this? I'm thankful the mitigation exists, dealing with many "temporary files" it saves me a lot of focus -- so i thought i'd share.

It turns out telemetry shows the number of people opening their downloads is up substantially from before 98 (ie by the millions), which basically indicates that just making the location of the downloads panel more obvious (and using it to replace the old confusing "what do you want to do with this file" dialog) is making a positive impact on people's lives. That's the majority of the userbase that we're supporting, and so that (ie people who, for instance, struggled to find their downloads in Firefox's UI) is who the changes are catered towards. I'm sorry this makes things worse for you, but the data suggests you're in a relatively small minority.

Reasonable people can disagree, but those number could be interpreted in different ways. FF98 basically prompted everyone to interact with an element and so they did. I did too. Cause I started deleting files which weren't meant to be permanent from the download dialogue. I'm that statistic too, though not by choice. I'd also refrain from calling invested people a "minority" after they went through the trouble of looking something up, reading up on it, opening an account at a bug tracker and sharing their experience. Looking at the market share, FF is the minority. I'd wish we wouldn't divide us even further. This community has made some really hard and really smart choices, but removing this functionality is not one of them.

Case: Client. Public sector. 1200+ employees. Many forms and documents changing when legislation changes. We found that ppl kept working with outdated documents; sending them each other by mail and going back to these once they needed them again. Centralized the whole thing. Rolled out FF wherever possible. Trained them in: go there -> click open with -> do your thing -> print and be done. Dramatically reduced friction. I suspect that ppl, now that the file is downloaded to their disk, will start using these outdated versions again -- since they are right there. None of them will show up here and share their experience.

snaps/flatpaks of Firefox need to put downloaded files somewhere [where other apps can read them].

Looking at my 22.04 development release where Canonical has pinned the FF snap at 500, i noticed a folder called "firefox.tmp" inside the "Downloads" folder. Used for, well, temporarily storing downloads and moving them once finished.

Let's be smart here and find a solution based on the new implementation. Could we, say, get that firefox.tmp folder and a pref, where, if you actively pre-selected open in (see Bug 1747343) and flip that pref, that folder would be used but files not moved to Downloads? This would preserve the new flow and add the choice back to differentiate between temp and permanent downloads.

Comment 47

[Shane Hughes [:aminomancer]]

(In reply to lrdix from comment #43)

One more thought on this: You argue people can deletes file using the download panel. Well, why don’t you think they could find a file there they just opened and wouldn’t be looking for in tmp, too? If you now say they wouldn’t be looking in the downloads panel, because they didn’t intend to download it, I say: They wouldn’t use the panel to delete it, because they didn’t even notice the file being downloaded.

I see your point there, but there are also some differences between the present status quo (files save to default download dir, files can be opened OR deleted via the panel) and the previous situation (files save to an obscure temp dir, files can be opened via the panel but not deleted). For one, being able to open a file via the downloads panel is useful, but there are some circumstances where it may not be shown in the panel (downloaded in a previous session, user cleared the panel, etc.). And generally speaking, many users may just want to be able to find the download, not necessarily open it.

You're probably thinking mainly of scenarios where the file is obviously temporary junk you just wanna view (almost as if it's a webpage) and forget about. I do this a lot with PDFs, for example. But sometimes you may download a file of a type that you normally want to open in Firefox (and so configure that way), but this time you want to save it and maybe move it onto a network drive, duplicate it, rename it, etc. So you want to be able to find the file. It's also possible that you want to open the file now, but still may want to revisit it later, or give it to someone else. Who knows?

There are so many possibilities, so it seems unreasonable to foreclose on all but 1 of them by default, just assuming that the user only cares about the file temporarily. In my mind, this is just another of the many cases where there is no one-size-fits-all approach, where having multiple options can only help. So I am always advocating in that direction, but I also understand that Firefox has thousands of preferences already, and very little room to expose them in the preferences UI. Every new preference adds extra baggage. So any new preference has to prove its merit. I think if such a preference existed, I would use it, but the objective value of this one is clearly debatable.

There's another aggravation with the Temp folder. Now, I for one was a fan of Firefox's Temp folder feature. But as a default behavior it was problematic because the Temp folder can become totally huge. Idk about you, but I restart my computer maybe once every 3 months. My Temp folder (on Windows 10) currently has something like 3500 files/folders in it. Merely opening the Temp folder in a file manager causes intense lag as it retrieves all the metadata to display, and not on any weak hardware. It was quite frustrating to have to deal with that, so even though I initially protested, I've come to find that removing that behavior has solved some problems for me.

That said, saving the file in the Temp folder is only one half of the old behavior. It also used to schedule the file for deletion (upon exiting Firefox). So, it would be possible to reimplement the latter as an option (say a preference called browser.download.openDeleteTemporaryFileOnExit) without reimplementing the Temp folder behavior — that is what I proposed here in bug 1759779. The nuance of where such files would be saved, if not the Temp folder, could be a topic for discussion.

But anyway, I don't think debating this further or trying to vote or "second" previous arguments is going to go anywhere, and it's just going to wear people out so they are less likely to work on this. The interests of subsets of users are always going to be in conflict, but some users are more willing and able to post comments on bugzilla than others.

It's apparent now that the Temp folder behavior is only user-friendly for users who know what to expect, who take notice of the fact that those files are automatically deleted. I can imagine my parents or grandparents being very surprised by this and potentially losing valuable data as a result. My inclination would be to err on the side of caution, even if it incurs some other costs, if it means sparing a few users that kind of catastrophic data loss.

And anyway, the users who have noticed this and complained are the least likely to have trouble setting preferences, so this kind of feature doesn't need to be the default. I don't yet know exactly what would be involved in adding a preference to this effect, or whether it requires changing anything in the core download code. But if it can be done without inflicting damage on the default flow (files permanently saved in user's default downloads dir), then in my opinion it's worth adding 1 new opt-in pref for.

And if anyone has some constructive feedback or suggestions to offer regarding an optional setting to make the "Open" action either 1) move the file to a special folder, e.g., TmpD, and/or 2) schedule the file to be deleted on exit, then maybe it would be wise to post that in bug 1759779 instead of here.

These are nearly identical requests, but it's easier for me to keep track of my own, it's less cluttered with debates, and I'm going to work on the patch myself so it's more likely to actually go somewhere. As far as I know, a pref for this can be added without causing serious problems for the mainstream, but since user data seems to indicate that most users wouldn't use such an option, it's unlikely anyone else is gonna commit time to resolving this one. And just repeating the same arguments and demands isn't gonna tip the scales. But if I can submit a relatively polished patch with a test, I think it will at least get a review.

Comment 48

[lrdix]

(In reply to Shane Hughes [:aminomancer] from comment #47)

(In reply to lrdix from comment #43)

One more thought on this: You argue people can deletes file using the download panel. Well, why don’t you think they could find a file there they just opened and wouldn’t be looking for in tmp, too? If you now say they wouldn’t be looking in the downloads panel, because they didn’t intend to download it, I say: They wouldn’t use the panel to delete it, because they didn’t even notice the file being downloaded.

I see your point there, but there are also some differences (…) For one, being able to open a file via the downloads panel is useful, but there are some circumstances where it may not be shown in the panel (downloaded in a previous session, user cleared the panel, etc.). And generally speaking, many users may just want to be able to find the download, not necessarily open it.

Maybe I am failing to see your point now, but I think you are wrong here. To me, it looks like your are actually not seeing my point. I think, a user who opened a PDF in an external app didn’t want to download it and consequently won’t be wanting to find the file on his machine, because they won’t even know it is or was there. They think it is gone and they have to find it online again. And yes, of course, if you clear the panel, there are no files being shown in the panel. That’s the whole point of clearing it. That’s no argument against using tmp.

But sometimes you may download a file of a type that you normally want to open in Firefox (and so configure that way), but this time you want to save it and maybe move it onto a network drive, duplicate it, rename it, etc. So you want to be able to find the file. It's also possible that you want to open the file now, but still may want to revisit it later, or give it to someone else. Who knows?

Yes. No. Seriously? If I want to download a file to somewhere, I do that. I save it there. It is never going to be in tmp except at the beginning of the download, until I choose the final destination, but that doesn’t matter. Because of that I don’t have to “find” a.k.a. look for it anywhere. I put it where it ultimaltely needs to go. And if I open it first, I can still save it where I want it to be. If the software I open the file with doesn’t allow for that, it’s that software’s fault. FF doesn’t have to cover that. It would never occur to me to blame FF, when a workflow breaks because of another app. This, too, is no argument against using tmp.

There's another aggravation with the Temp folder. Now, I for one was a fan of Firefox's Temp folder feature. But as a default behavior it was problematic because the Temp folder can become totally huge. Idk about you, but I restart my computer maybe once every 3 months. My Temp folder (on Windows 10) currently has something like 3500 files/folders in it. (…)

Well, what can I say. Restart your machine. Don’t use Windows, if you don’t have to. That’s really no good reason for moving away from tmp.

That said, saving the file in the Temp folder is only one half of the old behavior. It also used to schedule the file for deletion (upon exiting Firefox). So, it would be possible to reimplement the latter as an option (say a preference called browser.download.openDeleteTemporaryFileOnExit) without reimplementing the Temp folder behavior — that is what I proposed here in bug 1759779. The nuance of where such files would be saved, if not the Temp folder, could be a topic for discussion.

I think someone rejected that a long time ago.

But anyway, I don't think debating this further or trying to vote or "second" previous arguments is going to go anywhere, and it's just going to wear people out so they are less likely to work on this. The interests of subsets of users are always going to be in conflict, but some users are more willing and able to post comments on bugzilla than others.

And again, I cannot agree. Seconding previous arguments at least shows that there might be more people thinking that way than the developers estimated. And I am not merely repeating the arguments. I have the strong feeling that certain things are not being understood. Even though they have been explained in several different ways. Btw, I am repeating questions, too. To no avail, as it seems. The more I hear against using tmp, the more it sounds to me that there is a rather academic thinking behind all that, more than a real world problem:

(from comment #16)

Also (even though it could just be confirmation bias) I feel like there are far more people/nerds pissed off by the loss of a much appreciated and useful feature altogether, than the thing potentially breaking once in a blue moon and then having to patiently fill out a bug report.
If I can explain.

(In reply to Shane Hughes [:aminomancer] from comment #47)

It's apparent now that the Temp folder behavior is only user-friendly for users who know what to expect, who take notice of the fact that those files are automatically deleted. I can imagine my parents or grandparents being very surprised by this and potentially losing valuable data as a result. My inclination would be to err on the side of caution, even if it incurs some other costs, if it means sparing a few users that kind of catastrophic data loss.

I repeat myself: No. That’s not apparent. I don’t think people are expecting a file they didn’t consciously download to be saved anywhere. I have helped a lot of “grandparents” and the likes with computers. I have never observed such a behaviour. This is academic. I think, you are trying to solve a problem that simply doesn’t exist, and making life hard for many other users by doing so.

As far as I know, a pref for this can be added without causing serious problems for the mainstream,

Well, ask those who do the testing (see :Gijs’ comments above).

but since user data seems to indicate that most users wouldn't use such an option,

I think there are way more than you can imagine. Just look at all the debating here, and comments all over the web, and …

Comment 49

[lrdix]

To me, Bug 1759756 seems to be one more good reason to return to using tmp.

Comment 50

[lrdix]

Same with Bug 1759670.

Comment 51

[lrdix]

(In reply to Dalacor from comment #37)

3. The single biggest frustration is that on some Firefox 98/98.01 versions, I go into settings and find the application area and there is no entry for pdf's. So basically for clients who either want to set to (always ask) or to always open with - they have no way to change this setting - so everything is now downloading to the downloads folder all the time. So it appears the only way to fix this is to script this!

I don’t know about scripting and Firefox, but it appears there is a way to roll out Firefox preferences in enterprise environments via scripts (maybe like group policies for Windows?). Couldn’t that be a way to handle issues with tmp or other folders being on remote machines? The defaults would be as they had been before 98, and if there are issues, admins have a tool to handle them, by scripting where to temporarily save files instead.

Comment 55

[Shane Hughes [:aminomancer]]

(In reply to lrdix from comment #48)

With respect to the pref proposal being rejected, the main issue is this bug has already been resolved wontfix. My previous comment was about why the harm would mainly arise from this being the default behavior. I don't think a change to the default behavior is likely to happen, and every mozilla employee who has posted their remarks has militated against it.

Whereas the reasons not to add an opt-in preference are as I listed: it requires work despite having relatively narrow benefit confined to a subset of power users, and it makes the code base slightly more complex. But I offered to do the work myself, so like I said before, I think I can at least get a review for it. In any event, even if everyone were to relent and work on reverting the default behavior to save "Opened" files in TmpD and schedule them for deletion, it would probably be locked behind an experimental pref at least for a release version or 2. So there's no reason to be so hostile to the user pref idea, it's the best chance of getting what you want.

Comment 56

[John]

I know it's useless at this time to reiterate what a terrible idea it is for FireFox to permanently download a file to my computer without my permission when I simply view a PDF file using Adobe, but it is simply wrong for any program to do that. I cannot repeat enough that such behavior is simply wrong. Somehow the question of whether it is saved to a temporary file or not seems to have been mixed in with whether the "Always Ask" option is selected, but it has nothing to do with that. It has been mentioned that the download is triggered long before the "Always Ask" dialog is displayed. That seems rather irrelevant since at the time the download is triggered it has to indicate where the file is to be downloaded. At that point why is it so hard for FireFox to use a simple IF..Then to find out whether to use the temp folder or the download folder?

Comment 57

[heinrichmartin]

I was about to write a new bug "Firefox pollutes Download directory" since version 98. After browsing this (and a few related) bugs, I know that I am late to the party, but stable users will always be.

What was (seemingly) not yet said/suggested:

• If copying from /tmp was a technical issue (sometimes), then FF should use the cache for prefetching.
• The user's download directory does not belong to FF - an application should write under $HOME only (1) with explicit user consent or (2) to assigned (per-user-)config directories.
  • Consider whether users would accept a copy of all web images in their Pictures directory.
• If reverting is not an option (and neither is the cache), then maybe a customizable prefetch directory is a way forward, i.e. power users could configure an initial download directory that is different from the final ("always save to") download directory.

What was already said, but is worth mentioning:

• FF should not strive for uniformity with consumer grade browsers but do their best for their tech-/open-/privacy-/security-oriented users - to not lose them.
• Open-and-forget is still a badly needed feature - and if that collides with newer development, make it configurable.
• The internet is not the only browsable entity; there are many https-powered on-site applications.
  • Btw, FF is my only PDF-Viewer - Adobe is gone because it had pushed online-/cloud-/intrusive features too much!
• The user is always right.

Comment 59

[mirh]

Philosophical dilemmas about consent and rights are all nice and dandy, but the truth is that the average joe just wants to be spoon-feed everything as seamlessly and intuitively as possible.
There's nothing wrong with wanting to bother with other things in life, and appeasing the majority of people def pays the bills.
So, let's not bother too much with what the default is.

Although you'd really need some usability study to definitively assess how many times the previous behaviour was annoying (as opposed to now, where whatever the problem could be is kinda kicked down the road into the users hands), it'd be pretty difficult for one size to fit all. And it's better if it's tech-/power- users to have to open the scary settings menu.
Also, it's not like they really have much other options to switch to anyway (but you could argue "realistically" that casual users don't tend to switch from the browser they were assigned regardless of the difficulties they have, because they are too noob).

Anyhow, I think it had been already settled some dozen comments ago that not caring about this wasn't really some "technical nogo" or explicit refusal, but more something to do with available manpower. I don't think further "demonstrating" the current situation is subpar is needed.
Thanks Shane for the willingness, and hopefully he'll be able to work something out before browser.download.improvements_to_download_panel is removed.

p.s. I'd like to remember everybody that you can vote issues at the top of the page.

Comment 61

[Shane Hughes [:aminomancer]]

(In reply to John from comment #56)

I know it's useless at this time to reiterate what a terrible idea it is for FireFox to permanently download a file to my computer without my permission when I simply view a PDF file using Adobe, but it is simply wrong for any program to do that. I cannot repeat enough that such behavior is simply wrong.

What do you mean by view a PDF file using Adobe? Can you give some more details on that workflow? If Firefox is re-downloading files that are already on your file system, it sounds like a separate bug. If a PDF file is already saved on your file system and you open it in Firefox, it's not supposed to re-save it on your system. Firefox can open all sorts of files using the file:/// protocol. But if you open some web file, Firefox needs to save it somewhere.

It's always going to download a file to your computer. The only questions are where it's saved and whether it's permanent. Firefox is the only browser I know of that even bothered scheduling files for deletion, so this idea that it's "simply wrong" doesn't hold any water. It's a convenient quirk but hardly an industry-standard feature.

There's nothing in the UI that gives the impression that choosing "Open" would make the file somehow less permanent. It's something we have come to expect from having used Firefox, but it's not self-evident. Honestly I think if this was going to be added back as the default behavior, it would make sense to change the label from "Open" to "Save File Temporarily and Open" or something. That would at least mitigate somewhat the risk of unexpected data loss.

But like I said before I think most of the harm would already be alleviated by just making it an opt-in pref.

Somehow the question of whether it is saved to a temporary file or not seems to have been mixed in with whether the "Always Ask" option is selected, but it has nothing to do with that.

What do you mean? Firefox currently does not save files in the temp folder at all unless you manually select the temp folder via the "Save As..." dialog. (or toggle the temporary experimental pref browser.download.improvements_to_download_panel)

It has been mentioned that the download is triggered long before the "Always Ask" dialog is displayed. That seems rather irrelevant since at the time the download is triggered it has to indicate where the file is to be downloaded. At that point why is it so hard for FireFox to use a simple IF..Then to find out whether to use the temp folder or the download folder?

Nobody is saying it's hard for Firefox to do that. It's trivial. But for an "if-then" statement, you need a condition. What would it be checking? A user preference?

Comment 62

[Csaba Bencze]

(In reply to Shane Hughes [:aminomancer] from comment #61)

There's nothing in the UI that gives the impression that choosing "Open" would make the file somehow less permanent. It's something we have come to expect from having used Firefox, but it's not self-evident. Honestly I think if this was going to be added back as the default behavior, it would make sense to change the label from "Open" to "Save File Temporarily and Open" or something. That would at least mitigate somewhat the risk of unexpected data loss.
I disagree with this. You choose if you want to save it OR open it. It is a single choice. Nothing is indicating that if you choose Open it will be also saved. If you want to save it you select "Save", it is that simple. So if anything "Open" should be renamed to "Save to default download folder and open".

I think there was nothing wrong with how it worked. Maybe some people had problems with it, but I think more people have problem with the new behaviour. It was working like this since forever, you can't expect us to just adapt to a worse experience after all these years, just because other browsers do it this way. Firefox should be different from other browsers, that makes it appealing to switch to it.

The only real solution for this problem (considering that going back is not an option) in my opinion is to allow us to select where to save opened files separately from the default download folder.

Please make it work, it is crucial for may of us.

Comment 63

[Dalacor]

I have commented earlier on this thread. I believe that the issue has discussed from all viewpoints so I won't repeat what has already been said.

I will state that I have been using Firefox since it was Phoenix. I have been very happy with the browser primarily because the settings were so easy to change unlike Internet Explorer which had far too many confusing settings etc. I also like the ability to customise Firefox adding/remove the homepage button, moving where the icons are situated etc. That for me is great. I also love ublock origin and last but certainly not least the ethos of privacy settings that Mozilla foundation adheres to. So Firefox for me has always been a great browser and very reliable. Even the Firefox initial load time has been fixed as Firefox now starts up almost instantly which is a massive improvement over years past. So I really appreciate that.

Some of the upgrades over the years has felt like a step backwards at the time - especially the loss of the ability to open a new tab with the url set to be the homepage. That is one feature I do miss. But not a deal breaker in the end. But would be nice to get that feature back.

However, I am in agreement with many other users complaining about the new Firefox open/save functionality in version 98. I don't want my downloads folder to be a temporary folder for Firefox. It is not going to work for me or my clients. I have already suggested in the bug that I opened - see link in my earlier post - the option of having a C:\Users%Username%\Downloads\Firefox View and C:\Users%Username%\Downloads\Firefox Save Folders so that users can find files that they have saved in the Firefox Save Folder and Viewed in the Firefox View folder. This would solve all our problems and goals of Mozilla as I do agree that saving opened files to the Temp folder does have disadvantages. But making the downloads folder the new temp folder is not an option for us. It needs to be in a subfolder of the downloads folder at the very minimum to separate it from all the other documents that people save into the Downloads folder (deliberately save that is).

As I said, I have been very happy with Firefox over the years despite the loss of some functionality, but this is one change that is not going to work for us. We have moved to Firefox ESR, partially because of this issue and partially because this is the third Firefox issue we have had this year (Webroot and Firefox issue recently) and before that there was an issue in January something to do with https3 I believe. So the ESR version makes sense for us. But if Mozilla still has the downloads folder as the new temp folder when you release version 102 of Firefox ESR in June, then I am afraid we will have to move to Microsoft Edge. I am not prepared to have my browser clutter the downloads folder with files that we only want to view and will never open. This is not going to work for myself or my clients. I feel it is important to make this clear because this is one change that is definitely not wanted by myself or my users and is in fact would necessitate a move to another browser that doesn't do this. So I hope that you will reconsider this implementation and address the concerns of users who don't want their downloads folder to be a temp folder.

Comment 64

[rsbrux]

My confusion comes from the fact that the setting "Always ask you where to save files" under "Downloads" now appears to be overridden by any settings "Save file" under "Applications". Before v98, I had all PDF types set to "Save file", but the setting "Always ask you where to save files" ensured that I would always be prompted where to save them. Since 98, I am forced to change all of the individual application settings (of which there are many) from "Save file" to "Always ask". Why has the relative priority of these settings changed?

Comment 65

[:Gijs (he/him)]

(In reply to rsbrux from comment #64)

My confusion comes from the fact that the setting "Always ask you where to save files" under "Downloads" now appears to be overridden by any settings "Save file" under "Applications". Before v98, I had all PDF types set to "Save file", but the setting "Always ask you where to save files" ensured that I would always be prompted where to save them. Since 98, I am forced to change all of the individual application settings (of which there are many) from "Save file" to "Always ask". Why has the relative priority of these settings changed?

It shouldn't have changed. It sounds like you're seeing a bug, which either way is unrelated to this one (which is about whether we use the temp folder for files that are opened, whereas the issue you describe appears to be about files that you are deliberately saving, rather than opening). Please file a separate issue with more details about your setup -- if I try to do the same thing you're describing, based on your description alone, I get the results you want without changing any application settings to "always ask", so we'd need to investigate why you're seeing something else, and this bug is not the right place to do that.

Comment 66

[mrabb]

I am on Firefox 98.02

I have read most of the comments above and the Developers implementation of this new functionality is poor. While the old method which caused no issue with my workflow was decided to be too confusing, the new method left me with duplicate files.

I had opened a bunch of PDFs from the web intending to view all of them and with some would use the download functionality to save the PDF that I was viewing to a particular location. Now I was able to save the PDFs that I wanted after viewing a bunch of them. But I noticed that every one that I had viewed I had a copy of in my Downloads folder as well as another copy of the ones that I chose actually to download.

I was afraid of using the delete file option on the downloads dialog since I was not sure it would delete the files that were in the download folder (that I did not want) or the files that I "saved as" in the folder location that I wanted it to. So I manually went to my download folder and deleted a bunch of files that I did not know that I had even downloaded.

Considering that the browser user has set their preferences already to prompt to "Save As"... I can not understand, even if you changed the location from tmp/temp to the download folder why you choose to download and keep a file that the user has not even been given an opportunity to decide where the file is to go. If I wanted all of the downloads to just sit in the Download folder then I would have kept the defaults. If I have my preference set to prompt then I want that preference to be honored.

So in my opinion this project is getting out of focus tying to chase Chrome, rather than be the be the best browser on its own strengths.
This functionality was important to me and if I had another decent browser to switch to on Linux, I would switch because of this issue.

The Devs that are pushing this may think they are right but if Firefox keeps going down this road they will end up like the last revision of the Netscape browser. You should listen to the other comments that are against this change to find a way that this can be made better.

I have been a Firefox user since the beginning... before it was even 1.0. Do not double down on this... find a compromise please.

Comment 67

[Shane Hughes [:aminomancer]]

(In reply to mrabb from comment #66)

Considering that the browser user has set their preferences already to prompt to "Save As"... I can not understand, even if you changed the location from tmp/temp to the download folder why you choose to download and keep a file that the user has not even been given an opportunity to decide where the file is to go. If I wanted all of the downloads to just sit in the Download folder then I would have kept the defaults. If I have my preference set to prompt then I want that preference to be honored.

The choice of default action never controlled how "Opened" files are saved or whether they're automatically deleted. The difference now is that the "Open" behavior uses the default download directory instead of trying to use a temp directory, and that it no longer adds the downloaded file to a list of files to be deleted when Firefox exits. See my previous comments as I already replied to most of these remarks

Comment 68

[Martin Z]

It's plain to see from the comments above that

• quite a few users are annoyed with the new download workflow, while
• the developers think they have done great work

Unfortunately, both groups are right from their respective point of view, which does not help in finding a solution. I like tough problems, though, so what about this:

• files downloaded by Save file are saved to ~/Download/
• files downloaded by Open with are saved to folder ~/Download/temp (after explicitly activating this in the settings)

Why is this a solution?

1. power users like me can enjoy the old workflow and simply delete ~/Download/temp, either manually or from a cron script
2. if a power user opened a file and later chooses to download it, it is obvious which is the correct one
3. power users enjoy a clean ~/Download/ folder
4. at the same time, average users can enjoy the new download workflow, which is probably more intuitive than the old one

I'm looking forward to hear your opinion! :)

Maybe this should have gone into a new bug report / issue / whatever, but I'm not used to Bugzilla and wanted to write my idea down before it vanished into nothingness...

Comment 69

[mrabb]

@Shane

I did read the previous comments.
I just wanted to give my own perspective on the problems that this change is giving for my workflow.
I am just a plain longtime user, I am sure you have good reasons for making this change.

I agree with Martin Z and will hope that something like that could be done or have an extra setting that would work this way.

However, for myself I am voting the only way that I can vote. I will vote with my feet and folk will probably say good riddance :) ;)
I really can not believe I am going over to Microsoft Edge on Linux... but it works with my workflow.

I really hope that you can improve this new functionality and I will check back from time to time but I will not join the other voices to beat a dead horse here. Clearly your minds are made up and I do thank you for at least trying to continue to engage even if you have given your "final" answer so many times.

I wish the Firefox project and all of the hard working DEVs the best of luck!
I grew up using Firefox, so many good memories... I remember installing Phoenix [pre-name change] and loving it... So many changes over the years.

Comment 70

[mrabb]

Sorry I mean to say @Gijs (he/him) and not @Shane (sorry)

Comment 71

[Dalacor]

Thank you you mrabb and martin z for putting it more diplomatically than I have. I really hope that a change of direction will come about as I can see from reddit and many other forums complaining about this issue that I won't be the only one walking away if this change is permanent. This is not a small minority of people unhappy about the change - some of the forums on reddit are a bit harsh discussing the change.

Like mrabb I have been with Firefox since Phoenix days and I have always loved Firefox. But this change of making the downloads folder the new temp folder is unworkable for many users and in actual fact just creates more unwanted file clutter making it harder to find a file you have downloaded deliberately. I am not sure why there is a need to follow Chrome. If I wanted Chrome, I would go with Chrome.

I will endorse mrabb's good wishes to the Mozilla team as they have done a fantastic job over the years. It has not gone unnoticed. So it does feel like the end of an era for me if I have to move away because of this downloads temp folder issue. I look forward to seeing what Firefox 99 will be like.

Comment 72

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to :Gijs (he/him) from comment #3)

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.

This is now the default behavior on Edge, btw.

Comment 73

[lrdix]

(In reply to Martin Z from comment #68)

(…) so what about this:

• files downloaded by Save file are saved to ~/Download/
• files downloaded by Open with are saved to folder ~/Download/temp (after explicitly activating this in the settings)

You mean like Bug 1759779?

Comment 74

[Martin Z]

(In reply to lrdix from comment #73)

(…) so what about this:

• files downloaded by Save file are saved to ~/Download/
• files downloaded by Open with are saved to folder ~/Download/temp (after explicitly activating this in the settings)

You mean like Bug 1759779?

A bit like that, but much less involved (if I understood bug 1759779 correctly). I'm a developer myself and strive to keep things simple, because the result will be more resilient and easier to understand for users. I guess these are the main reasons why the new download workflow was introduced in the first place, and scheduling downloads for automatic deletion would make it brittle again (files won't be deleted in case Firefox crashes, deleting a file while it is still open in an application might not work etc.).

My idea is to simply have two download folders, the outer one (~/Download) being used as default location for all downloads and the inner one (~/Download/temp) being used for "opened" downloads. Automatic deletion is not necessary. A power user on Linux could still point a symlink from ~/Download/temp to /tmp, but would be on his own in terms of security and system reliability.

The option should be clearly visible in the main settings window, something like:
[ ] Store opened files in Downloads folder
[x] Store opened files in sub-folder "temp" of Downloads folder

I'm happy to rephrase my thoughts and add them to bug 1759779 if this is of any help.

Comment 75

[Shane Hughes [:aminomancer]]

(In reply to Martin Z from comment #74)

You're right that the historic behavior includes 2 distinct actions: 1) save the download target in the temp folder, 2) schedule the download target for deletion when Firefox ends. But I totally disagree about automatic deletion not being necessary. That's the central feature. I think many users would complain and consider this bug unresolved if we restored 1 of those actions but not the other.

If all that is necessary is for downloads to be saved in a single folder that can be cleared out periodically without significant mental effort, then we don't have much of a problem here in the first place, and can leave this resolved wontfix. And anyway, there's no reason not to support scheduled deletion if we're already going to the effort of adding an opt-in pref to support some kind of temporary downloads system, since nsIExternalHelperAppService already exists, ready to be used. It doesn't require any additional effort at this point.

(files won't be deleted in case Firefox crashes, deleting a file while it is still open in an application might not work etc.).

The fact that there are special circumstances when an action will fail is not a reason to never attempt the action. You could say the same thing about user-initiated actions, like the new 'Delete' menu item for downloads, but we don't get rid of those actions just because they have failure conditions.

Btw, I think only certain types of crashes will stop the files from being deleted, depending on which component causes the crash. Edit: Also, Firefox will successfully delete files that are in use, at least by most other applications. Go ahead and try it with the "Delete" menu item. Downlod a text file, choose "Open with [text editor]", then open the downloads panel, right click the download, hit Delete. If you have VS code or something that shows this, it will show that the source file has been deleted.

But in any case, the external helper expunge function will fail gracefully if it fails at all. If something happens to stop it from expunging the files, let's say the external helper app service itself somehow breaks, that only means that the file will need to be deleted some other way. Either by the user or by the operating system.

That's one of the reasons why the operating system's temp folder is better than an ordinary subfolder in the Downloads folder. It will eventually be emptied without need for user interaction. But even if the OS temp folder is not used, that just means most files will be automatically deleted, and occasionally a few will not be. So then the user would have to delete some manually. How is that any worse than not automatically deleting anything? If Firefox doesn't try to expunge the files, then that means the user has to delete even more files manually.

Afaict, the only downside to expunging the files that seems to be resolved by not expunging the files is that the user may not want some files to be deleted. May not have intended that they be treated as "temporary" files. But that's only resolved by the current status quo, where no files are treated as temporary files at all.

Think about it, what's the difference between 1) automatically deleting opened files, and 2) placing opened files in a special folder that the user can delete without thinking about it? Option #2 just means the user becomes the agent of the automatic deletion, rather than the application. The whole point of saving files in ~/Download/temp is that the user can delete it without scanning through it to check which files specifically they want to delete. So if there's a file in there that they don't want to be deleted, it makes no difference who deletes it, Firefox or the user.

If, on the other hand, the user realizes that there may be files in ~/Download/temp that they don't want deleted, then they're going to have to scan through it by hand before emptying it. In which case, why does it need to be ~/Download/temp? Why can't the files just be saved in ~/Download? What purpose is served by placing the "opened" files in a special folder, if the special folder requires just as much mental effort to clean up as the regular downloads directory?

So we circle back to the status quo: all downloads are treated as permanent, the user is the agent of their deletion, and Firefox stays out of the business of deleting downloaded files. This seems better than a situation where Firefox creates a subfolder in an ordinary directory all by itself. At least, users won't be lulled into a false assurance that they can absentmindedly empty the folder without losing data, and blame Mozilla when they wind up deleting their tax organizer or whatever.

That's why I believe there should be 2 main options: 1) the default option that prioritizes data safety and simplicity over productivity, treating all downloaded files the same; and 2) the "power user" option, that must be enabled by the user, with the opposite priorities, basically restoring the old behavior of writing to TmpD and scheduling the files for deletion (as Firefox currently does when the pref browser.download.improvements_to_download_panel is disabled).

Option #2 could possibly improve on the old behavior by creating a temp folder if one can't be used or can't be located (aforementioned snap/flatpak builds). Maybe that is better than letting the user choose a path. But it's more complicated to develop. I think the nuances can be worked out later, the fastest way to respond to user feedback will be to add a pref that makes the default action save files in TmpD and call the expunge function on them. This is simple because we are already checking for browser.download.improvements_to_download_panel in those places so it just means adding && !Services.prefs.getBoolPref("browser.download.openSavesFilesTemporarily", false)

The option should be clearly visible in the main settings window, something like:
[ ] Store opened files in Downloads folder
[x] Store opened files in sub-folder "temp" of Downloads folder

"Store opened files..." is not really clear to someone who isn't familiar with this discussion. Files can be opened from Firefox in more ways than this bug pertains to. The only thing that (with the downloads improvements disabled) moves the target of user-initiated downloads to the temp folder is the initial download action.

So that includes the default action, i.e., the one bound to the content type handler for the download (configured in about:preferences), as well as the action specified by the user in the unknown content type dialog (the dialog with radio buttons "Open with [branding name]", "Open with [menulist]", and "Save file") — since that's basically presented to the user as a selector for the initial action.

The unknown content type dialog currently only opens if the content type handler has been set to "Always ask", which is not the default. For most users the most common action will be to save the file automatically, or to open the "Save as" dialog, whereupon they can open the file by clicking it in the downloads panel or the "all downloads" view in the Library window. But those "open" actions won't cause the download to be treated as temporary in any way.

I'm afraid the proposals in bug 1759779 are confusing too. I haven't been able to think of a user-facing presentation that adequately conveys what the pref would change and under what conditions. But presentation can be considered a separate issue. Most people who are bothered by these changes will probably hear about a new pref that can be set in about:config.

Comment 76

[Martin Z]

(In reply to Shane Hughes [:aminomancer] from comment #75)

Your comments are quite valid. I should have made more clear what I had in my mind when writing my comment. Here we go ...

(from comment #3)

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).

From reading this, I understood that using /tmp is not a good idea (and I won't event speak of the temporary folder mess in Windows). Thus, I proposed using a sub-folder in the Download folder.

In regard to not deleting temporary files automatically, I was indirectly referring to the proposals in bug 1759779. I understood that files should be deleted immediately when not needed any more, which seems a bit too involved. But pruning the temporary folder (wherever it may be) by download date - say seven days later to have a bit of time for recovering important files - is something that seems a good idea.

But I'm not intimate with the internals of Firefox or the functions you mentioned, so your comment may be more to the point than mine.

Comment 77

[Shane Hughes [:aminomancer]]

The problem arises from downloads writing to a volume before their final destination is determined. That's why I think restoring the old behavior by default would not be an improvement for most users. As an opt-in pref, it's definitely gonna come with some kind of drawback, but by setting the pref, the user consented. If the architecture is left the same then the drawback is gonna be that downloads generally can fail, because they're all going through the temp folder on the boot volume, before any interaction that would set launchWhenSucceeded.

Alternatively, the architecture could be changed (behind the pref of course) to add some kind of preliminary stage where information is collected and the final destination is set, and only use the temp folder if launchWhenSucceeded (or perhaps if the final destination = the boot volume and not on macOS). That would be a lot more complicated so at best that might be a long-term goal. I didn't mention it in my bug report because at the time I thought it was a pretty small number of users complaining. Now it seems more urgent so that may be worthwhile.

In any case, the pref should be 1) automatically deleting the launchWhenSucceeded files, and 2) sequestering the launchWhenSucceeded files in some kind of temp bin. They're simple on their own, but I think either one without the other causes problems for the user.

Combining your proposal with the automatic deletion seems like the simplest proposal (that is, fastest to land). I'm not really a fan of Firefox creating its own subfolder in an ordinary directory (in this case an important, universal one like ~/Downloads), and I'm especially not a fan of Firefox sort of colonizing it with a prune cycle or something. It just seems kind of ad hoc, and I would lose my mind if every browser, email client, chat client, etc. did the same thing. But that is the only approach that doesn't require major changes to the external app handler service or telling the user who opts into this to just tolerate errors. So for the time being, as long as we combine it with scheduled deletion, that seems appropriate.

That requires us to basically move the file on downloadDone. Keeping the changes away from the external app handler would minimize the amount of new test coverage needed.. I think. If there aren't any objections, I can work on a patch to that effect, except without any settings UI exposure because I still don't have any idea how to concisely represent this option to the user.

Comment 78

[Dalacor]

I think what would be helpful is clarification on why Firefox 98 changed the download/open behaviour and from us clarification as to why this is a problem.

Why this is an issue for end users:

1. Many people save different documents into the downloads folder as a sort of a temporary area for files that they are working on, but don't intend to keep. So the downloads folder needs to contain just the files that end users explicitly download from the Internet, Email or from another area of their drive or server shared areas. Otherwise the downloads folder becomes clogged with hundreds of files that the average viewer views on their Sharepoint, accounting program etc.

2. Many websites like accounting programs have pdf's attached to data eg pdf invoices. If you are an accountant working on Xero all day long, you definitely don't want every single client's pdf documents sitting in the downloads folder because you opened a number of pdf's in their business. There are a lot of websites like that where there are documents on the "portal" and you simply want to view the documents as that is the "file Share". You never want to download these documents or hardly ever as the only time would be when you might want to send a copy to someone. Hence the need to auto delete all these opened documents as they will quickly mount up to thousands in a year.

So in short, end users don't want the downloads to be the new temp folder. Second, there are many documents on the web that you might only want to view, but never download, so again you don't want this cluttering up the downloads folder. - there should be either be an auto delete option or failing that a unique temp folder used just by Firefox.

Why Mozilla changed the historic behaviour:

1. There are technical issues saving to the temp folder. I am not sure what those technical issues are, but I understand it to be something to do with the number of files in the folder as windows, IE etc all save in this folder? However, my suggestion and the suggestion of some others would be to have a unique temp folder that is only used by Firefox. This would negate these technical issues? I don't actually know what technical issues there are, so I don't fully understand what issue is being solved here.

2. Users didn't know that files that they opened were saved to the temp folder. So if they ever wanted to keep the file, they had no idea how to find it again. I can see the value in this point as - while extremely rare - even I once in a blue moon closed a file that I had opened and then later decided to go back to that file. Hence my suggestion above for a unique temp folder that is only used by Firefox and is located in the Downloads folder making it easy for non technical end users to find this "temp" folder.

3. Auto deletion of files means that if a user wants to view a document again, they have to find the website and document again and re-open it or explicitly download it. I can see the argument against auto deletion, but I would suggest something along the lines of Microsoft Storage Sense, where I would set the files in this temp folder to be deleted after 30 days. If you haven't used it within 30 days, you are unlikely to. So a storage sense concept of deleting after 30 days or any time period up to 3 months that the user wants.

4. Firefox no longer asks users what to do with default files such as pdf's. The new download makes it easier for non technical users and defaults to downloading. This is not an issue, if power users can change this via user.js file or within the application area itself.

My Proposal for all users

Create two folders in the downloads folder. I would call them Firefox Opened and Firefox Saved, but the exact names are not important to me.

Make the file action defaults whatever Mozilla deems appropriate for the user base. My preference would be "always ask" so I can choose to save the file or open the file and more importantly open with my pdf viewer program installed on Windows, not the browser version. But as long as the end user can change this to whatever they want - this is not a major issue. I can understand the desire to make this easy for non technical end users.

With one exception. I have set all my clients to true for the pdfjs.disabled settings to disable the browser pdf. However on upgrading to version 98, more than one user reported that suddenly pdf's were just downloading - the always ask option was not working and even worse when I went into the application area to reset the default option for pdf's, there was no pdf entries anywhere. So whatever changes you make in future, you need to ensure that Firefox will default to always ask if the browser pdf is disabled.

The Firefox unique temp folder can have a setting somewhere in Firefox to delete all files older than x number of days in the temp folder. I believe that this would meet the goals of making it easier for users to find a file that they opened and which was subsequently saved in the "temp" folder. You could even split the downloads panel into two tabs - downloaded files and opened files! I think that would work well

Final Thoughts

I actually disagree with the opinion that having a Firefox "temp" folder in the downloads is a bad idea. I think it is a very good idea - it just seems odd because it has not been done before. But it makes it a lot easier (for even people like me) to view files that were opened versus downloaded if you go with my suggestion of having a tab option in download panels to view files that were opened or view ones that were downloaded. You solve the main issue removing it from the system temp folder and using 30 days or 3 months or even disabling storage sense (which is windows default) and the user explicitly has to tell Firefox to delete files in this temp folder after x number of days!

It would also make your job easier as you said creating a temp folder in Downloads is minimal work, instead of restoring the historic behaviour. I think the biggest issue (from our point of view) is that we don't understand the technical issues of why the temp folder is a bad idea as we are not programmers (or at least I am not), so it's hard to suggest improvements as I don't 100% understand what technical issues are being resolved by moving away from the temp folder. So I have no idea if my temp folder (that myself and others have suggested) within the downloads folder actually fixes the underlying technical problems.

I, at the very bare minimum (and what I would suggest) is create a Firefox View (temp) folder in download and a Firefox open folder in downloads and then get feedback from users on that change. Then later on, move onto questions about auto deletions like Microsoft storage sense and whether this should be enabled/disabled by default. So fix issue one - which is to get the temp files that Firefox creates out of the main downloads folder. Then get feedback and move onto the next issue like auto deletion. For me, auto deletion (on say 30 days) would be great, but my bigger priority is to get the temp files out of the main downloads folder. Not forgetting the need to fix the issue where the pdf entries have vanished if you have disabled the Firefox pdf viewer.

I think the only other question that needs to be reviewed is whether Firefox should save temp files and downloaded files in the downloads folder. I can see the argument against temp files being in a temp folder in the downloads folder. If every program did this, it would be a mess. Some programs already create folders within users documents folder and it's so untidy. But I can't think of a better place to save the temp files as users are already used to the downloads folder being their default save to location - although with my users we default to always ask to force users to save to the correct folder location on the servers.

Comment 79

[lrdix]

It’s a bit of a bummer that some questions aren’t being answered by Mozilla, but I think the solution being discussed here could be a good alternative to the old behaviour. Just two thoughts:

(In reply to Dalacor from comment #78)

4. Firefox no longer asks users what to do with default files such as pdf's. The new download makes it easier for non technical users and defaults to downloading. This is not an issue, if power users can change this via user.js file or within the application area itself.

I wouldn’t want to have to create and look after a user.js file just because I am more on the power user end of the user spectrum.

Then, as I said, I don’t use, don’t have and don’t want there to be a directory $HOME/Downloads. I am very strict when it comes to what I have in my $HOME and what not, so I would need an option to choose whatever directory as new temp, even something like $HOME/.ff-tmp, $HOME/.local/tmp, $HOME/.mozilla/tmp or whatever, without there being a downloads folder. Same on Windows, where I don’t use those predefined folders like My Documents, My Pictures and so on. On Windows, I would go for something like %USERPROFILE%\fftmp. I just don’t want to see that stuff anywhere, as it is merely garbage to me (not meaning that in a negative way, but the files in question get downloaded in order to be opened, and that’s it). And I would be very thankful, if I wouldn’t have to delete them myself, so an option inside Firefox like automatically delete [] upon quitting Firefox, [] after [__] days (fill in) would be really nice, maybe even [__] seconds after download competed.

Comment 80

[Dalacor]

(In reply to lrdix from comment #79)

(In reply to Dalacor from comment #78)

4. Firefox no longer asks users what to do with default files such as pdf's. The new download makes it easier for non technical users and defaults to downloading. This is not an issue, if power users can change this via user.js file or within the application area itself.

I wouldn’t want to have to create and look after a user.js file just because I am more on the power user end of the user spectrum.

I am referring to enabling users to change the defaults via the application settings in Firefox Settings OR via the user.js file. You can do it either way. The value of the user.js is for scripting changes to many client computers. Naturally I still want to be able to change the settings within Firefox settings itself. I am not suggesting that power users need to use user.js, but that is useful to deploy to many computers.

Then, as I said, I don’t use, don’t have and don’t want there to be a directory $HOME/Downloads.

You are entitled to choose what you want for your downloads folder. The suggestion that I am making is more the default location for the millions who can barely switch their computer on. Obviously for power users being able to change the downloads/temp locations would be ideal. However for Joe Public, I suspect the downloads folder on windows (and whatever the Linux equivalent is) would be best for the general public who are not good with IT.

Comment 81

[Shane Hughes [:aminomancer]]

(In reply to Dalacor from comment #78)

Create two folders in the downloads folder. I would call them Firefox Opened and Firefox Saved, but the exact names are not important to me.

I don't think that's something a mainstream, general-purpose browser should be doing in 2022. It's the kind of thing that would be useful if you set out looking for it and found it in an add-on, but would be overbearing and awkward as the normative behavior in a browser. I might be able to create an autoconfig script that implements something like that, and I'm sure it would be very helpful to a subset of power users, but to thrust that kind of obscure, narrow behavior onto every Firefox user is way too much.

Because of the variety of people complaining about the loss of "temporary download" behavior, the solution (if any) should ideally be a preference for a behavior that's straightforward enough that it can be exposed in the preferences UI. Lots of users may know how to use about:config or user.js, but would be unlikely to find out about a specific preference. There are usually notes in the source code that can be located on searchfox, and there are some websites that catalogue individual prefs and their functions, but you have to know what you're looking for, or else go manually scrolling through about:config and searching every pref by name to find out what they do.

So, for most people to benefit from a preference, it needs to be explained in an interface that can be reached by conventional affordances like the app menu button or the menu bar — namely, the about:preferences page. And the vast majority of preferences are too narrow or too complicated to be exposed in about:preferences. I think we should be brainstorming about ways to make the preference more conventional and less technical so that there can be a checkbox for it in about:preferences. That's probably gonna mean compromising its usefulness to power users.

Comment 82

[Dalacor]

(In reply to Shane Hughes [:aminomancer] from comment #81)

(In reply to Dalacor from comment #78)
I don't think that's something a mainstream, general-purpose browser should be doing in 2022. It's the kind of thing that would be useful if you set out looking for it and found it in an add-on, but would be overbearing and awkward as the normative behavior in a browser. I might be able to create an autoconfig script that implements something like that, and I'm sure it would be very helpful to a subset of power users, but to thrust that kind of obscure, narrow behavior onto every Firefox user is way too much.

I made that as a possible suggestion to address the issue of all temp files now being downloaded into the downloaded folder. I agree, it's not the best solution and does feel like a hack in a way. To be perfectly honest, the best solution (for me and many others) is to go back to pre 98 so that temp files go to the temp files folder where in our opinion they belong.

I don't mind what solution Mozilla come out with as long as the end result (for the public, not just me) is that temp files (viewed documents) are not being saved in the documents folder as this is not a good location for these files. I agree, my suggestion is not optimal, but if Mozilla wants to move away from using the system temp folder, I am not sure what better option there is? Putting the temp files into the downloads folder is not an option that is acceptable. Many users on reddit, spiceworks etc are complaining about this very issue. So an alternative has to be found.

Comment 83

[Shane Hughes [:aminomancer]]

(In reply to Dalacor from comment #82)

To be perfectly honest, the best solution (for me and many others) is to go back to pre 98 so that temp files go to the temp files folder where in our opinion they belong...
Putting the temp files into the downloads folder is not an option that is acceptable. Many users on reddit, spiceworks etc are complaining about this very issue. So an alternative has to be found.

Well, I don't think this is a helpful way to frame the issue. Final download targets actually are not (and never were) "temp files" in the first place. "Temp files" are the .part files that Firefox is in the process of writing and which yield the final destination files. The fact that you're choosing to "Open" the files does not make them "temp files," it just makes them opened files. Some users want files to be "temporary" under certain circumstances. But what are those circumstances? Can everybody agree?

The behavior has to change, whether we try to implement something to replace it or not, because it was never consistent in the first place. The reason Firefox used to save these files in the Temp folder is not because it was trying to treat "Opened" files as temporary and treat others as permanent. I understand why some users may have that impression but that's not the case. Until recently, all downloaded files were saved and written in the Temp folder and then moved to their final destination.

My understanding is that the reasons were technical and historical. If the user chose the "Open" action, then the Temp folder was simply treated as the final destination. And, just as download targets are scheduled for deletion in private windows, the "Opened" files were scheduled for deletion in any window. But none of this happened to files that were "Opened" by any other means. They weren't intentionally made temporary. You can see that pretty easily by looking at the source code — all references to temp files in the code comments are references to part files.

The problems with saving part files in the Temp folder are 1) the Temp folder might be inaccessible, 2) it might be on a different volume than the final destination directory, and 3) the user is not initially expecting their files to be deleted or not deleted based purely on whether they choose "Open" or "Save", affordances which say nothing about the file being deleted. That's a serious issue that many users seem to be hand waving.

Nothing in the user interface refers to downloaded files as temporary. The only reason you keep calling them temporary and expect them to be placed in the Temp folder and automatically deleted is because you previously noticed that files opened in this way were located in the Temp folder. That is, because Firefox incidentally used to do that in the past, behind the scenes, for technical reasons. There is no user-facing explication of the behavior or any indication that they're temporary files.

So would a new user, approaching Firefox for the first time, expect any files to be saved in the Temp folder? Other applications typically only use the Temp folder for files that the user is not expected to interact with, like background installers, caches, etc. Certainly most other browsers don't refer to files downloaded by the user as temporary.

Incidentally, this behavior has had positive effects for some Windows and Linux users (including myself), who have noticed this unadvertised "feature": if you choose "Open" instead of "Save", you can open a downloaded file and expect Firefox to delete it for you. Now, that "feature" has been removed. Part files are saved in the user's download directory instead of the Temp folder, just like Firefox did on macOS. So, the users who noticed this quirk and began taking conscious advantage of it are perceiving a technical change as the removal of a feature.

But there's only one determining factor in whether Firefox moved the file from the Temp folder (a kind of staging area) to the Downloads directory or some other folder: the choice between the "Open" and "Save" affordances. A single word, each. And neither of those words gives any indication about the long-term survival of the file. So as you can see, the only reason a user would ever perceive this as a feature is if they 1) understand what a Temp folder is; 2) have manually changed Firefox preferences and file handlers to select "Open" or "Always Ask" instead of the default, "Save"; and 3) have used Firefox long enough, and have enough technical expertise, to have noticed or investigated the paths of download targets under various conditions.

So, clearly the old behavior has a serious problem in that it automatically deletes data and/or makes data vulnerable to automatic deletion without giving any user-facing indication of that. So, even if we could resolve the technical issues (the Temp folder might be inaccessible; it might be on a different volume than the final destination directory), we would still have a serious usability issue. The old behavior cannot simply be restored.

At the same time, some users have grown accustomed to their files being automatically deleted by the "Open" download flow, enough to find this so useful that its removal is a disaster. How should their interests be weighed against the interests of new or less knowledgeable users who are not expecting files to be deleted? And against the interests of users of snap/flatpak builds and users whose Downloads directory is not on their boot volume?

Well, IIUC the current behavior is the same as it already was on macOS. So, apparently lots of macOS users have been downloading files in Firefox for years without demanding that Firefox delete their files. That's why this "feature" was initially removed without any immediate replacement, and that's why Mozilla is not pushing for the changes to be reverted. It's not like the users here and on reddit are being ignored, as if their voices don't matter. I'm willing to spend my own time trying to find a solution that will please as many people as possible.

As was already mentioned above, alice0775 and I (among others) mentioned early on how these changes would impact power users who had gotten used to the behavior and were using it to avoid manual cleanup. So, we added the "Delete" menu item so that these files could be deleted from within Firefox. I worked on that and related issues (e.g., solving bugs caused by it) for like 3 weeks, and that was 100% motivated by the exact complaints you are expressing.

That menu item doesn't totally eliminate the user effort, but some amount of user effort is necessary for Firefox to ascertain whether the user actually wants the files to be deleted. Firefox can't just assume that anyone who chooses to "Open" a file also wants Firefox to delete the file. (Just because several power users have grown accustomed to Firefox doing that, against usability conventions, doesn't mean that's normal or good) So, either the file needs to be deleted by a "Delete" affordance rather than by an "Open" affordance, OR Firefox needs to expose some opt-in preference that explains clearly that it turns the "Open" affordance into an "Open and Schedule for Deletion" affordance.

Any further solution needs to account for at least some of the problems with the old behavior. In particular, it either 1) must not surprise users by deleting files without telling them it's going to do so; or 2) must be locked behind a preference that the user must opt into.

In addition, it would be nice if it avoided the problems with the Temp folder altogether. But we can't evade those problems at the expense of basic design conventions. Firefox making its own directories for background operations would be one thing, but placing all the user's downloads in special directories would deviate too far from user expectations. It would be jankier the previous proposal that involved making 1 special directory for just the so-called "Temp files" while leaving "unopened" files in the main Downloads directory. And that is already too janky for release builds I think.

Comment 84

[Dalacor]

I fully understand that files opened in Firefox were downloaded to the temp files folder in the past. I agree that they are not technically temp files, but I am using the word temporary in the context that many people associate open or viewed files as opposed to files explicitly saved.

I understand and support your desire to move away from the system temp folder as I do fully appreciate that there were technical and user issues with using the temp files folder for previous versions of Firefox.

None of above is in dispute. When I said I would prefer to go back to the old way, I simply meant that the new implementation is far from satisfactory and all things equal I would rather go back to the old way as I don't see the current design as an improvement. The bottom line is that the downloads folder is not a good location to save these opened files.

All I (and many others) are asking for is a solution where files that are opened/viewed are not saved to our downloads folder. How that is achieved is irrelevant to us.

https://www.reddit.com/r/firefox/comments/tdohiy/firefox_98_download_manager_support_thread/ Here is one thread providing feedback on the issue, with many users not happy with the new work flow. Thank you very much for your feedback. I agree with most of your points. There is no dispute that the old way had issues. The problem is the new way creates just as many, if not more issues than the old way.

Comment 85

[Martin Z]

(In reply to Shane Hughes [:aminomancer] from comment #83)

So, clearly the old behavior has a serious problem in that it automatically deletes data and/or makes data vulnerable to automatic deletion without giving any user-facing indication of that. So, even if we could resolve the technical issues (the Temp folder might be inaccessible; it might be on a different volume than the final destination directory), we would still have a serious usability issue. The old behavior cannot simply be restored.

At the same time, some users have grown accustomed to their files being automatically deleted by the "Open" download flow, enough to find this so useful that its removal is a disaster. How should their interests be weighed against the interests of new or less knowledgeable users who are not expecting files to be deleted? And against the interests of users of snap/flatpak builds and users whose Downloads directory is not on their boot volume?

Any further solution needs to account for at least some of the problems with the old behavior. In particular, it either 1) must not surprise users by deleting files without telling them it's going to do so; or 2) must be locked behind a preference that the user must opt into.

I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):

[ ] Keep all downloaded files
[x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.

The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Of course, I'm not sure whether this actually solves all the problems and can be implemented in a robust way. It's just an idea ...

Comment 86

[Csaba Bencze]

(In reply to Shane Hughes [:aminomancer] from comment #83)

Nothing in the user interface refers to downloaded files as temporary. The only reason you keep calling them temporary and expect them to be placed in the Temp folder and automatically deleted is because you previously noticed that files opened in this way were located in the Temp folder. That is, because Firefox incidentally used to do that in the past, behind the scenes, for technical reasons. There is no user-facing explication of the behavior or any indication that they're temporary files.

So would a new user, approaching Firefox for the first time, expect any files to be saved in the Temp folder? Other applications typically only use the Temp folder for files that the user is not expected to interact with, like background installers, caches, etc. Certainly most other browsers don't refer to files downloaded by the user as temporary.

While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

Comment 87

[Shane Hughes [:aminomancer]]

(In reply to Martin Z from comment #85)

I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):

[ ] Keep all downloaded files
[x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.

The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are Open in Firefox, Always ask (open a dialog that exposes the same action choices), Save file (opens a "Save as" dialog if the user has enabled that in the radio group above), Use OS default application, and Use other...

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to Open in any handler, but could be configured to Always ask. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like Open in Firefox) that save the file temporarily and open it. So that would add Save temporarily and open in Firefox, and Save temporarily and open in [OS default application], and Save temporarily and open in.... These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to Always ask (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Edit: Instead of adding "Save temporarily and" to all of those strings, we could split the dropdown menulist into sections and add menucaptions that make it clear what the following menuitems do. So for the temp options, the menucaption above them would say Save file temporarily and... and then the options would just say "Save file" or "Open with..." as they currently do. And the menucaption above the non-temp options would say Save permanently and... as you'd expect. So the menupopup would be separated into little semantic groupings to allow the strings to remain pretty short. That way we're not stretching it out beyond the normal width of the menulist column.

And as for the unknown content type dialog (prompted by choosing "Always ask" in about:preferences), a checkbox could be added to the dialog. The checkbox would either say Save file temporarily or Save file permanently, not sure which is clearer. That checkbox could either 1) feed back into the handler for the content type in question, so that user selection is saved per-content type; 2) record the user selection for the UCT dialog generally, such that it applies to all content types that are configured as "Always ask"; or 3) not save user selection at all.

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and its implementation would be much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)

While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's literally no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. We know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file and open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

Edit: Oh, I almost forgot. All other things being equal, it would be worse for the user to expect a file to be saved and have Firefox actually delete it than for the user to expect a file not to be saved and have Firefox actually save it. We want to err on the side of caution when the stakes are as high as unexpected data loss. So, files being unexpectedly saved might be the kind of thing we'd want to resolve, but that's minor enough to be on the level of an enhancement. On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

Comment 92

[Martin]

Why is this closed as WONTFIX?
This is a very annoying bug.

First of all, it's unacceptable that firefox puts files on my drive I never wanted it to put there.

That I have to now actively look through my download directory and manually delete downloaded files I never wanted there in the first place is just stupid design.

This new download thing is just terrible, it's worse than what we used to have.

At least please leave the option to use the old panel.

Who thought it was a good idea to force users to manually keep track of files they don't even want and delete them?

Comment 93

[Martin]

How is my previous comment advocacy?

I'm giving the reason why this is a very annoying bug. Files that are opened directly should be put in the temp directory.
This bug is so annoying that I'm wondering if using wget or curl wouldn't be simpler.

This is also a privacy violation. Firefox stores files in download directory without user's permission.

Comment 94

[Martin Z]

(In reply to Martin from comment #93)

This is also a privacy violation. Firefox stores files in download directory without user's permission.

With all due respect, this is a bit absurd. If you want a file to be opened, it needs to be stored somewhere. Thus, you gave permission by inference.

Actually, there has been no change from the old download handling in this regard. The only difference is that your operating system does not automatically delete "privacy-violating" files any more.

I am with you that the current solution is not great, but calling Firefox's design stupid and calling for lawyers is not going to fix it. That being said, I have a feeling that the discussion in this bug report may help to alleviate your (and my) pain.

Comment 95

[Martin]

(In reply to Martin Z from comment #94)

(In reply to Martin from comment #93)

This is also a privacy violation. Firefox stores files in download directory without user's permission.

With all due respect, this is a bit absurd. If you want a file to be opened, it needs to be stored somewhere. Thus, you gave permission by inference.

Before the change those files never touched my drive. They'd stay in /tmp.

Actually, there has been no change from the old download handling in this regard. The only difference is that your operating system does not automatically delete "privacy-violating" files any more.

There is a change. Before this was introduce I didn't have to lift a finger. I download a bunch of pdf files daily and I open them in Okular. I never intend to keep any of them. I didn't have to do a thing. Now? Now I have to keep tracking all the files and keep deleting them from my drive… every day… again and again. Were I a fluent English speaker I'd have found a better word to describe it, I'm not so I'm calling it stupid.

I am with you that the current solution is not great, but calling Firefox's design stupid and calling for lawyers is not going to fix it. That being said, I have a feeling that the discussion in this bug report may help to alleviate your (and my) pain.

The sad thing is that Firefox keeps getting worse to use. They waste time on this kind of "improvements" when the browser can't playback videos any more. If users report bugs they're closed as WONTFIX or labelled as advocacy and hidden.

Comment 96

[Shane Hughes [:aminomancer]]

(In reply to Martin from comment #95)

Before the change those files never touched my drive. They'd stay in /tmp.

/tmp is a folder on a volume on a drive. Actually, Firefox lets you choose which folder they go to via the path selector in about:preferences. And now, as of this change, it actually uses that folder when you choose "Open" instead of "Save file." Previously, it just wrote everything in /tmp irrespective of user preferences, and then only moved it after the fact (and didn't move it at all if you chose "Open"). The previous comments in this thread already clear up these misconceptions and explain the current situation, FYI.

There is a change. Before this was introduce I didn't have to lift a finger. I download a bunch of pdf files daily and I open them in Okular. I never intend to keep any of them. I didn't have to do a thing. Now? Now I have to keep tracking all the files and keep deleting them from my drive… every day… again and again. Were I a fluent English speaker I'd have found a better word to describe it, I'm not so I'm calling it stupid.

That's right, but none of that has any bearing on privacy or user permissions. The previous behavior was convenient for some Windows and Linux users, but it had a risk of download failure as well as unexpected data loss. What has changed is a matter of convenience, not privacy. Martin V is just trying to explain how your previous comment was a bit hyperbolic or melodramatic.

The sad thing is that Firefox keeps getting worse to use. They waste time on this kind of "improvements" when the browser can't playback videos any more. If users report bugs they're closed as WONTFIX or labelled as advocacy and hidden.

So what's the issue, downloads or video playback? If you have an actual problem with video playback you should be posting a new bug report about that. If it's so obvious to you the right way to improve Firefox, then why don't you submit a patch?

Where we're at right now (you'd know if you had read any of the previous comments) is trying to find technical solutions to the problems that make it difficult to use the Temp folder, and make it difficult to expose this concisely as a user preference. Everyone is aware that many users are frustrated by losing this "feature," but that doesn't help to write a patch.

Comment 97

[putr4.s]

/tmp is a folder on a volume on a drive.

On most Linux distros (at least Ubuntu, Fedora and Arch for sure) /tmp is mounted as tmpfs, aka a ramdisk, so Martin would be mostly correct in that those files wouldn't have touched any physical disks in those cases unless swap gets involved, and is automatically cleared on reboots.

Comment 98

[putr4.s]

(In reply to putr4.s from comment #97)

On most Linux distros (at least Ubuntu, Fedora and Arch for sure)

Sorry, I misremembered in Ubuntu's case as I haven't used it in a while (mixed it up with the fact that it does still clear /tmp on reboots, just checked that in a VM), but I do use both Fedora and Arch Linux and both mount /tmp on tmpfs. OpenSUSE Tumbleweed also switched to using tmpfs for /tmp according to this, not sure what the policy on Leap is.

Comment 99

[Shane Hughes [:aminomancer]]

Even so, a user can choose any folder on the filesystem they want, irrespective of the physical medium. It's not Firefox's fault that some media are volatile while others are not. On Windows (the most popular OS) the Temp folder is on the boot volume. Besides, if storing files on volatile media was some kind of basic human right that is necessary for privacy, macOS users would have been begging for volatile download storage for years. But nobody expected such a feature because it was only implemented on Windows and Linux (see here and here).

Comment 100

[Martin]

(In reply to Shane Hughes [:aminomancer] from comment #99)

Even so, a user can choose any folder on the filesystem they want, irrespective of the physical medium. It's not Firefox's fault that some media are volatile while others are not. On Windows (the most popular OS) the Temp folder is on the boot volume. Besides, if storing files on volatile media was some kind of basic human right that is necessary for privacy, macOS users would have been begging for volatile download storage for years. But nobody expected such a feature because it was only implemented on Windows and Linux (see here and here).

You're missing the point. You picked up on a single word from my post and are trying to discredit all the users' input about this feature.

storing files on volatile media

The whole point is that people DON'T want to store those files. They want to open a file without having to worry about cleaning up the downloads directory time and time again. What a waste of time this is. Can't you really understand this? Something that didn't require any actions from users now requires constant attention and active tracking of files people don't want to keep.

It used to work perfectly fine. Now that users are complaining and filing bugs you just ignore them. Look at how many duplicates this bug has. People hate this behaviour and you ignore them. This is why Firefox is loosing users.

Comment 101

[Adrian]

^ this.

I often download ZIP files which are opened with my file manager. I then extract+run something from it (or view a file in there) and the ZIP file goes away afterwards when I close the browser / my temp folder gets cleaned. I do not intend to keep that zip file around...

Comment 102

[lrdix]

It really can be a privacy issue or something alike, because of the way Firefox behaves now. With other browsers the user knows a file is being saved permanently. If you have been using Firefox for years, there is a very high chance that one day you are being surprised by many sensitive documents being saved permanently, while you were thinking you saw to it, that they are not being around anymore. Maybe someone has access to them (be it angry admins). Big issue!

(In reply to Martin from comment #100)

It used to work perfectly fine. Now that users are complaining and filing bugs you just ignore them. Look at how many duplicates this bug has. People hate this behaviour and you ignore them. This is why Firefox is loosing users.

While I think you do have a point, let me tell you, that this kind of comments is highly non-constructive. It is not opening anyone’s eyes as you might be thinking or hoping.

(In reply to Shane Hughes [:aminomancer] from comment #83)

The problems with saving part files in the Temp folder are 1) the Temp folder might be inaccessible, 2) it might be on a different volume than the final destination directory, and 3) the user is not initially expecting their files to be deleted or not deleted based purely on whether they choose "Open" or "Save", affordances which say nothing about the file being deleted. That's a serious issue that many users seem to be hand waving.

Just out of curiosity:

1. What is different about the temp folder than about a download folder? Is it about write permissions?
2. So, is it exclusively about tmp and downloads being on different volumes, local or remote, not about e.g. the final destination directory being on a remote volume? I can’t count files I have chosen to download into a directory on a server, while tmp was local. That has always worked.
3. I admit, concerning that point I may have been ignorant to a certain degree. However, I do think that the majority of average users is not looking for a file that was opened, expecting it to be saved, as the user was being given the choice between opening or saving, implicating that opening means to decide against saving.

Nothing in the user interface refers to downloaded files as temporary. The only reason you keep calling them temporary and expect them to be placed in the Temp folder and automatically deleted is because you previously noticed that files opened in this way were located in the Temp folder. That is, because Firefox incidentally used to do that in the past, behind the scenes, for technical reasons. There is no user-facing explication of the behavior or any indication that they're temporary files.

I understand that, and I don’t disagree, but I do think, that you, on the other hand, as a developer, are being trapped a little bit in your rather technical view, when it comes to determining a file as temporary or not. You, as a developer, considering opened files as non-temp, don’t want those files in a temp directory, and I understand that. The user, on the other side, doesn’t want files that were merely to be opened instead of downloaded to be saved in a download folder (i.e. downloaded), especially when the user chooses not to have a download folder. That is independent from whether the UI indicates those files being temporary or not.

So would a new user, approaching Firefox for the first time, expect any files to be saved in the Temp folder? Other applications typically only use the Temp folder for files that the user is not expected to interact with, like background installers, caches, etc.

I think we cannot know. Some users might expect all software to behave the same way, others might expect a different behaviour from a browser than from some other software. Those who come from, say, Chrome, are used to Chrome. They could be confused, they could be delighted. How can that be more important than the expectations of users who have been using Firefox for many years?

Certainly most other browsers don't refer to files downloaded by the user as temporary.

Yes, but the point is: We aren’t exactly talking about downloaded files. And as I understood comments here, other browsers only offer downloading, not opening. And if they do, they clearly state the file being downloaded, maybe even ask where to. There can’t be any direct comparison of Firefox’s behaviour with that of other browsers.

But there's only one determining factor in whether Firefox moved the file from the Temp folder (a kind of staging area) to the Downloads directory or some other folder: the choice between the "Open" and "Save" affordances. A single word, each. And neither of those words gives any indication about the long-term survival of the file. So as you can see, the only reason a user would ever perceive this as a feature is if they 1) understand what a Temp folder is; 2) have manually changed Firefox preferences and file handlers to select "Open" or "Always Ask" instead of the default, "Save"; and 3) have used Firefox long enough, and have enough technical expertise, to have noticed or investigated the paths of download targets under various conditions.

I think, you are overlooking one widespread case: Users with little technical expertise may not even be aware of the fact that a file has to be downloaded before it can be opened. And if the browser asks open or save, they very likely will think of this as XOR.

So, clearly the old behavior has a serious problem in that it automatically deletes data and/or makes data vulnerable to automatic deletion without giving any user-facing indication of that. So, even if we could resolve the technical issues (the Temp folder might be inaccessible; it might be on a different volume than the final destination directory), we would still have a serious usability issue. The old behavior cannot simply be restored.

Given what I said above, I don’t think eventually deleting opened files is a serious problem for usability, or for data safety. I think, that is too technical a view.

At the same time, some users have grown accustomed to their files being automatically deleted by the "Open" download flow, enough to find this so useful that its removal is a disaster. How should their interests be weighed against the interests of new or less knowledgeable users who are not expecting files to be deleted?

That is a point of view that should be thoroughly scrutinised!

And against the interests of users of snap/flatpak builds and …

I don’t know anything about flatpak/snap, but it seems to be more of a flatpak/snap issue. Maybe you have to tell them “sorry, with snap/flatpak this feature cannot be implemented as of today” somewhere in the UI/prefs. This doesn’t look like it should be considered Firefox’s fault.

users whose Downloads directory is not on their boot volume?

Could you elaborate on what exactly is the issue here (see above)? When you say boot volume, do you mean the partition from which Firefox is running, or the one on which the user profile is saved, or actually the boot partition?

Well, IIUC the current behavior is the same as it already was on macOS. So, apparently lots of macOS users have been downloading files in Firefox for years without demanding that Firefox delete their files.

Yes, but you do have to admit, that Mac is sort of an entirely different world, don’t you think? ;-) In my perception, people who prefer Mac UI/UX, generally have likings that are very different from those of other users (not weird, just different). Having to work with a Mac all day would be an absolute no-go for me (I have tried). I’d have to find a new job. No exaggeration.

It's not like the users here and on reddit are being ignored, as if their voices don't matter.

I have to say, it does feel like that.

I'm willing to spend my own time trying to find a solution that will please as many people as possible.

And that is very much appreciated.

As was already mentioned above, alice0775 and I (among others) mentioned early on how these changes would impact power users who had gotten used to the behavior and were using it to avoid manual cleanup. So, we added the "Delete" menu item so that these files could be deleted from within Firefox. I worked on that and related issues (e.g., solving bugs caused by it) for like 3 weeks, and that was 100% motivated by the exact complaints you are expressing.

I really appreciate that effort, too, and I am truely sorry that I have to say that this isn’t a satisfactory replacement. You still have to delete every single file you didn’t want to be saved in the first place. Whether you use a file manager or use the download manager as a file manager, there is still that same additional work to be done. In both cases you have to find the files in a list, select them and then delete them, except a file manager allows me to sort files by timestamp, type etc.

That menu item doesn't totally eliminate the user effort, but some amount of user effort is necessary for Firefox to ascertain whether the user actually wants the files to be deleted. Firefox can't just assume that anyone who chooses to "Open" a file also wants Firefox to delete the file. (Just because several power users have grown accustomed to Firefox doing that, against usability conventions, doesn't mean that's normal or good)

The user effort consists of the decision whether to save or open. It actually took years until I realised that opened files actually have to be downloaded before they can be opened (back then, before I became an engineer, as a noob ;-)). And again:

So, either the file needs to be deleted by a "Delete" affordance rather than by an "Open" affordance, OR Firefox needs to expose some opt-in preference that explains clearly that it turns the "Open" affordance into an "Open and Schedule for Deletion" affordance.

I am sure, not every user considers this a deletion of files. Technically it is, of course, but there isn’t that situation, that you want or don’t want a file to be deleted that you didn’t want to save in the first place.

Any further solution needs to account for at least some of the problems with the old behavior. In particular, it either 1) must not surprise users by deleting files without telling them it's going to do so; or 2) must be locked behind a preference that the user must opt into.

Same. I don’t think the surprise is as big as it may be looking from a developer’s point of view. To me, this seems to be the main pivot of the controversy. I have the impression that this isn’t being sufficiently considered and thought about.

(In reply to Shane Hughes [:aminomancer] from comment #87)

Edit: Instead of adding "Save temporarily and" to all of those strings, we could split the dropdown menulist into sections and add menucaptions that make it clear what the following menuitems do. So for the temp options, the menucaption above them would say Save file temporarily and... and then the options would just say "Save file" or "Open with..." as they currently do. And the menucaption above the non-temp options would say Save permanently and... as you'd expect. So the menupopup would be separated into little semantic groupings to allow the strings to remain pretty short. That way we're not stretching it out beyond the normal width of the menulist column.

This approach seems very technical. I think, you shouldn’t have it say “Save file temporarily and …” and then “Save file”.

And as for the unknown content type dialog (prompted by choosing "Always ask" in about:preferences), a checkbox could be added to the dialog. The checkbox would either say Save file temporarily or Save file permanently, not sure which is clearer.

They’re not synonymous, are they? As a user I would be wondering what the first means.

(In reply to Csaba Bencze from comment #86)

While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically.

It didn’t before 98! I think you suspect wrongly, see way above, and what you just quoted from Csaba’s comment.

It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

From my experience with normal users, I wouldn’t say that it is abundantly clear. You have to notice that little symbol in the first place, than give it some thought, try it, find out what it does, and so on. How many average users do that? How adventurous do you consider the majority of users?

(…) In that case, there's literally no indication that the file is going to be (…) deleted. (…) That's obviously a recipe for confusion (…) Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file and open it, that's only a presentation issue. (…)

Edit: Oh, I almost forgot. (…) On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

Here, you are circling back to the potential misunderstanding of normal users, and of course, if I choose to save a file somewhere, Firefox or any other software has no right whatsoever to delete it, unless I tell it to do so. But that’s far remote from what we are talking about, which is merely opening a file and then basically forget it (or save it afterwards, but that’s a new situation). I fail to see that big peril of confusion.

As to currently unclear and presentation issue I am not following atm.

Comment 103

[Adrian]

That menu item doesn't totally eliminate the user effort, but some amount of user effort is necessary for Firefox to ascertain whether the user actually wants the files to be deleted. Firefox can't just assume that anyone who chooses to "Open" a file also wants Firefox to delete the file. (Just because several power users have grown accustomed to Firefox doing that, against usability conventions, doesn't mean that's normal or good)

The user effort consists of the decision whether to save or open. It actually took years until I realised that opened files actually have to be downloaded before they can be opened (back then, before I became an engineer, as a noob ;-)).

I started using web browsers when you had the choice between Internet Explorer 6 and Netscape. Even IE6 back then had "Save" and "Open" with the latter saving to the temporary directory and then opening the file from there. So this behavior has been consistent 20 years ago, and those who moved on from this (by now terrible) browser got the same (very decent, IMHO) behavior in Mozilla/Firebird/Phoenix and eventually Firefox, and usually clearly appreciated it.

So with this change you are actually forcing people to adapt to a new pattern that they got used to for TWO DECADES. Do you really believe anyone who's using Firefox since that long does not KNOW and LIKE the current behavior?

Sorry, but I always read about "new users". Sure, "new users" metrics are cool to show to management. But do you metrics on how many of the old users actually like keeping behavior they got used to for literally more than half their life? How many of them are power users who DO know such things? How many of them LIKE the fact that Firefox lets you customize its behavior in many ways (about:config is awesome!)? My guess is the answer is "no" because we are the type of users that:

• typically do not post on social media about their browser, because it's a tool that works fine, and is not worth talking about [unless something like THIS happens that screws things up for them]
• tend to be privacy-aware and thus disable telemetry
• are may even consider contributing something back to the browser (for the subset of these users that are developers)

To be honest, if there was an about:config switch to override the download location for "open" (that could be set to the temp dir), I think all of us would already be happy. You wouldn't even need UI for it, just an about:config setting.

Or a way for extensions to override this, without changing any other behaviors. Yes, webextensions are nice (not as as invasive and error-prone as legacy extensions), but there's a good chance that an extension CANNOT do this in a nice way - I remember looking at a "force open file in browser" extension (so probably using similar APIs than for the problem this issue is about) after the move to webextensions. The webextension alternative was MUCH worse, and IIRC. it even broke for some cases (downloads starting from a POST request, because the extension tried to start it again but as GET or with some data missing).

Comment 104

[Shane Hughes [:aminomancer]]

(In reply to Adrian from comment #103)

So with this change you are actually forcing people to adapt to a new pattern that they got used to for TWO DECADES. Do you really believe anyone who's using Firefox since that long does not KNOW and LIKE the current behavior?

If you had read any of my comments you would know I do not think that. All of my proposals in this thread mention and are motivated by the expectation that long-time Windows/Linux users will have become accustomed to this behavior. I don't know why you people keep dispatching personal attacks against me. Everything you feel entitled to is already mentioned in my proposals above. Maybe the reason is because I'm apparently the only person you haven't alienated out of this thread.

To be honest, if there was an about:config switch to override the download location for "open" (that could be set to the temp dir), I think all of us would already be happy.

Again, if you had read a single of my comments you would know I was already working on a patch to add a user pref (see bug 1759779 as well). I am waiting for feedback from employees to my proposals that are like 20 comments up, and you are just getting in the way of them ever seeing my suggestions. Nobody wants to comment now because this whole thread is scorched earth. You're actually hindering the fulfillment of your own demands just because you can't resist the temptation to scapegoat and ridicule a volunteer for a mild inconvenience in a browser you've been using for free.

You wouldn't even need UI for it, just an about:config setting.

This just shows how little thought you've actually given this. Ironically, you just got done telling us that anyone who uses Firefox will expect Firefox to put "Opened" files in the Temp folder (assuming a Temp folder exists and is accessible). If you're right and I'm wrong, then there are many thousands of users (at least) who demand this, but will not learn that a pref has been added.

Firefox has thousands of prefs. It doesn't notify users when a new one is added. It also doesn't describe what they do and what the range of valid values is. A user would never know about this hypothetical new pref unless they followed this bug report or bothered reading aimlessly through the source code. Hence, my numerous comments brainstorming a concise graphical representation in about:preference. "just don't bother because I'm already CC'd to this thread" is what that sounds like.

Or a way for extensions to override this, without changing any other behaviors. Yes, webextensions are nice (not as as invasive and error-prone as legacy extensions), but there's a good chance that an extension CANNOT do this in a nice way - I remember looking at a "force open file in browser" extension (so probably using similar APIs than for the problem this issue is about) after the move to webextensions. The webextension alternative was MUCH worse, and IIRC. it even broke for some cases (downloads starting from a POST request, because the extension tried to start it again but as GET or with some data missing).

WebExtensions is outside my area of expertise and this is already technically complex enough that I probably can't do it alone, so I have not proposed anything like that. I think the implementation would be much more difficult, and users would then have to wait for an add-on developer to make use of the API for their needs to be fulfilled. A patch for a user pref exposed in about:preferences would resolve these complaints immediately.

Comment 105

[Shane Hughes [:aminomancer]]

(In reply to Martin from comment #100)

You're missing the point. You picked up on a single word from my post and are trying to discredit all the users' input about this feature.

Let's see, I'm replying to putr4.s' comment #97, not yours, so I'm not picking up on any words from your post. I never even replied to your post because it's hidden.

storing files on volatile media

The whole point is that people DON'T want to store those files. They want to open a file without having to worry about cleaning up the downloads directory time and time again. What a waste of time this is. Can't you really understand this?

This doesn't make any sense. I'm replying to putr4.s' comment, which is about the /tmp folder being located on a ramdisk on certain Linux distros. A ramdisk is a volume on volatile media (DRAM).

The claim that people don't want to store files is utterly meaningless, because downloaded files have to be stored and have always been stored. A ZIP archive can't be viewed like a webpage. It has to be downloaded to a filesystem be used at all. What changed in Firefox is not that Firefox started storing files it never stored before.

I've already explained this in like 3 or 4 of my previous posts, so this is gonna be the last time I do it: Firefox used to write part files in the Temp directory and then move them to the final destination. When the user chose "Open," that last step was basically skipped. Now, Firefox writes part files in the user-specified Downloads directory (set by preference browser.download.dir), and then moves them to the final destination. As before, when the user chooses "Open," the file remains in the Downloads directory.

That is done because downloaded files are not webpages. They cannot just be held in memory. Even webpage resources are not merely held in memory, but are stored on the filesystem in caches. So I said in my previous comment that ANY web browser is going to need to store files on the filesystem no matter what, and that this can't possibly be a "privacy violation" because it's been part of the basic functionality of all web browsers (except maybe Tor browser) for decades.

Then putr4.s replied by mentioning that the /tmp folder can sometimes be on a ramdisk and therefore be volatile by nature. I don't think this is relevant, because it's still storing the file on the filesystem. It's really not substantially different from the Temp folder on Windows, which is stored on the (almost invariably non-volatile) boot volume, but is cleared by the operating system under certain circumstances. Either way we're dealing with files being stored and then being deleted later.

Comment 106

[Martin]

(In reply to Shane Hughes [:aminomancer] from comment #105)

The claim that people don't want to store files is utterly meaningless, because downloaded files have to be stored and have always been stored. A ZIP archive can't be viewed like a webpage. It has to be downloaded to a filesystem be used at all. What changed in Firefox is not that Firefox started storing files it never stored before.

Sorry but you're missing the point. People are angry exactly because now they're forced to keep the files they don't want to keep. They have to actively keep track of files they don't want and delete them, in perpetuity.

I've already explained this in like 3 or 4 of my previous posts, so this is gonna be the last time I do it: Firefox used to write part files in the Temp directory and then move them to the final destination. When the user chose "Open," that last step was basically skipped. Now, Firefox writes part files in the user-specified Downloads directory (set by preference browser.download.dir), and then moves them to the final destination. As before, when the user chooses "Open," the file remains in the Downloads directory.

This isn't how it's worked for me. Since I can remember the part file was always created in the destination directory along with the destination file that is of size 0 until the download is finished. I don't remember it ever working differently. I've just checked on a VM and that's how it works.

That is done because downloaded files are not webpages. They cannot just be held in memory. Even webpage resources are not merely held in memory, but are stored on the filesystem in caches. So I said in my previous comment that ANY web browser is going to need to store files on the filesystem no matter what, and that this can't possibly be a "privacy violation" because it's been part of the basic functionality of all web browsers (except maybe Tor browser) for decades.

Firefox goes and puts the file to my download directory behind my back. I don't want this. From the user point of view those are temporary, inconsequential files. I shouldn't be forced to track and delete them all the time. I want to view a pdf in Okular, I don't want to keep the file, I don't want it ever touching my drive. /tmp (of course it's tmpfs, that it needed explaining is strange to me) is a good place to put that file. Other would be the user dir under /run (which too should be backed by tmpfs).

Then putr4.s replied by mentioning that the /tmp folder can sometimes be on a ramdisk and therefore be volatile by nature. I don't think this is relevant, because it's still storing the file on the filesystem. It's really not substantially different from the Temp folder on Windows, which is stored on the (almost invariably non-volatile) boot volume, but is cleared by the operating system under certain circumstances. Either way we're dealing with files being stored and then being deleted later.

Please look at it from the point of view of the user. People are angry because they are forced to track and delete files they never intended to keep. It's creating a mess in downloads directory and wastes users' time.
Before this was introduced it wasn't a problem at all. Files were put in /tmp and the user didn't have to worry about anything, they hadn't even thought this could be an issue… until Firefox made it an issue.

Comment 107

[Shane Hughes [:aminomancer]]

(In reply to lrdix from comment #102)

It really can be a privacy issue or something alike, because of the way Firefox behaves now. With other browsers the user knows a file is being saved permanently. If you have been using Firefox for years, there is a very high chance that one day you are being surprised by many sensitive documents being saved permanently, while you were thinking you saw to it, that they are not being around anymore. Maybe someone has access to them (be it angry admins). Big issue!

The fact that something might be surprising is not a justification, in and of itself, for never doing it. Especially when it's resolving longstanding problems. The band-aid has to be ripped off eventually. I don't need you to explain to me what it's like to have used Firefox for years. If you had read through my comments (both in this thread and in others) you would know I've done more to accommodate users who expect the Temp folder behavior than anyone else posting manifestos in here.

I advocated for preserving the old behavior, even if it is defective, in an opt-in user pref, months ago. When my advice wasn't taken, I spent some 15 hours of my own personal time writing and revising patches to add a "Delete" menu item so downloads could be deleted from within Firefox, with the express purpose of compensating for the fact that they will no longer be automatically deleted. And now I am trying to find a way that, for users who opt into a pref, downloads can still be either saved in the Temp folder or automatically deleted when Firefox exits.

I would have more time to work on that, and it would be easier for Mozilla to respond to my proposals, if new manifestos weren't constantly being added to this thread and if my comments were actually visible out of the 100+ other comments in here. I keep saying you guys aren't helping by spamming this thread, you're just causing Mozilla employees to remove themselves from the CC list and making it harder for them to see my proposed changes that are waiting for some general approval or rejection.

(In reply to Shane Hughes [:aminomancer] from comment #83)

The problems with saving part files in the Temp folder are 1) the Temp folder might be inaccessible, 2) it might be on a different volume than the final destination directory, and 3) the user is not initially expecting their files to be deleted or not deleted based purely on whether they choose "Open" or "Save", affordances which say nothing about the file being deleted. That's a serious issue that many users seem to be hand waving.

Just out of curiosity:

1. What is different about the temp folder than about a download folder? Is it about write permissions?

Yes, and that a temp folder doesn't even exist on some OSes.

2. So, is it exclusively about tmp and downloads being on different volumes, local or remote, not about e.g. the final destination directory being on a remote volume? I can’t count files I have chosen to download into a directory on a server, while tmp was local. That has always worked.

It doesn't matter if the volume is local or remote. Like I said in my previous posts, what matters is that Firefox begins writing part files in the same folder, no matter where it is, because it needs to start downloading the file before the user has chosen where to ultimately save the file. Where the file should end up depends on whether the user chooses "Save" or "Save as." If the user chooses Save, then the final destination will ultimately be the user's specified default Downloads directory. If they choose Save As, then the final destination could be anywhere.

The reason that matters is because the final destination may be on a different volume. My own workstation has 9 (local) volumes with wildly different characteristics. Some are NVMe drives, some are hard drive RAID sets, some are SATA SSDs, etc. My final downloads folder is on a local NVMe drive, but it's not the one hosting my boot volume. My boot volume (C:/) is on NVMe 1. My final downloads folder (J:/Temp Downloads) is on NVMe 2. Those two volumes have different unused capacities.

The same dilemma would happen if NVMe 2 was on a network share. It makes no difference what the connection protocol is, what matters is that the volumes are simply not the same. So let's say C:/ has 250GB used out of 500GB, and J:/ has 1.99TB used out of 2TB. And let's say I'm using Firefox 97, so the old Temp folder download saver behavior is still prevailing. When I begin a download (let's say a .zip file of 50GB), the target starts writing to C:/Users/me/AppData/Local/Temp since I'm using Windows 10 (like most of Firefox's users).

After the download begins writing, Firefox prompts me to specify what should happen to it, because I have configured ZIP archives to "Always ask". So Firefox opens the unknown content type (UCT) dialog. The UCT dialog has radio buttons whereby I choose whether Firefox will simply save the file or try to launch it after saving it. Let's say I've chosen J:/Temp Downloads as my downloads folder, and I've left the other preferences untouched, so that if I choose the Save option, Firefox will not open a "Save As" dialog.

So, the final destination now depends on which option I choose in the UCT dialog. If I choose "Save," then Firefox will try to move the download from C:/Users/me/AppData/Local/Temp (where it's writing the part files) to J:/Temp Downloads (the final destination, according to my preferences). If instead I choose "Open," then Firefox will simply leave the download in C:/Users/me/AppData/Local/Temp.

But there's a big problem: I said "J:/ has 1.99TB used out of 2TB". When I choose "Save," Firefox will mysteriously fail to save the ZIP archive where it's supposed to go, because the ZIP archive is larger than the remaining space on the final destination volume.

Now let's say I update to Firefox 100. Currently, Firefox doesn't write part files to the Temp folder at all. Instead, it writes part files to the user-specified Downloads directory. So, if I follow all the aforementioned steps, the download will always be on the same volume from start to finish and will fail when the user expects. It won't cryptically move the download across volumes. We can have other problems that are caused by moving across volumes aside from this storage discrepancy issue, by the way.

Of course, whether on Firefox 97 or 100, you can get the same issue by using the "Save As" dialog. If you choose to save the file on a different volume than either the Temp folder or the user-specified Downloads directory, then the download may fail at the end. But the difference is that in Firefox 97 that can happen whether you use "Save As" or "Save," while in Firefox 100 that can only happen with "Save As" (which isn't the default setting).

And if the download is going to fail, we'd prefer that it fail at the beginning so that 1) the user doesn't potentially waste 30 minutes waiting for a big download to finish before it fails, and 2) the cause can be anticipated, allowing a popup or something that can alert the user that they should check the storage space. In Firefox 97, such a popup might be misleading as it may instead be a permissions issue, and it's hard for Firefox to tell the difference.

3. I admit, concerning that point I may have been ignorant to a certain degree. However, I do think that the majority of average users is not looking for a file that was opened, expecting it to be saved, as the user was being given the choice between opening or saving, implicating that opening means to decide against saving.

I only mention that as a further argument amid numerous others. As I have repeatedly said:

(In reply to Shane Hughes [:aminomancer] from comment #87)

All other things being equal, it would be worse for the user to expect a file to be saved and have Firefox actually delete it than for the user to expect a file not to be saved and have Firefox actually save it. We want to err on the side of caution when the stakes are as high as unexpected data loss. So, files being unexpectedly saved might be the kind of thing we'd want to resolve, but that's minor enough to be on the level of an enhancement. On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

I'm just pointing out that, in addition to that argument, I don't think all other things really are equal. If they were, then we should still err on the side of avoiding data loss. But on top of that, I think it's much weirder and more unexpected for Firefox to write all files in a special system folder and automatically delete them at some indeterminate time in the future, than for Firefox to permanently save all files that are downloaded, irrespective of whether you chose to "Open" or "Save" them.

Nothing in the user interface refers to downloaded files as temporary. The only reason you keep calling them temporary and expect them to be placed in the Temp folder and automatically deleted is because you previously noticed that files opened in this way were located in the Temp folder. That is, because Firefox incidentally used to do that in the past, behind the scenes, for technical reasons. There is no user-facing explication of the behavior or any indication that they're temporary files.

I understand that, and I don’t disagree, but I do think, that you, on the other hand, as a developer, are being trapped a little bit in your rather technical view, when it comes to determining a file as temporary or not. You, as a developer, considering opened files as non-temp, don’t want those files in a temp directory, and I understand that. The user, on the other side, doesn’t want files that were merely to be opened instead of downloaded to be saved in a download folder (i.e. downloaded), especially when the user chooses not to have a download folder. That is independent from whether the UI indicates those files being temporary or not.

To be clear, I'm not a "developer," I am a Firefox user since 2006. I began contributing code to Firefox on a purely voluntary basis earlier this year. I don't have a particularly technical view. I have only learned how the Downloads code works about a few months ago, in the course of writing patches that were intended to accommodate users (like myself) who grew accustomed to Firefox automatically cleaning up "Opened" downloads.

In any case, it's not a "technical view" but simply a fact that Firefox saves all downloaded files, and that files don't have some kind of "temporary" bit. It's not that I "don't want" something. In point of fact, I'm the one trying to make a user pref that will put the files in the Temp folder and schedule them for deletion (again, see bug 1759779).

If that pref existed, I would use it myself. But I'm not holding my breath — for all the loud noises and harsh words being bandied about, nobody else in here has contributed even the slightest thing to that goal. Instead they've just continued harassing me with every post, spamming everyone's email inbox, and probably causing Mozilla employees to unsubscribe from this thread.

This has absolutely nothing to do with personal opinion or interpretation of words. There just is no such thing as "temporary files," so I'm trying to get people to stop publishing polemical manifestos in here that seem to take for granted that "Opened" files are somehow temporary, and that Firefox is violating some kind of civil right by not deleting them. It's not a helpful way to frame the dialogue, since it's factually incorrect.

I think we cannot know. Some users might expect all software to behave the same way, others might expect a different behaviour from a browser than from some other software. Those who come from, say, Chrome, are used to Chrome. They could be confused, they could be delighted. How can that be more important than the expectations of users who have been using Firefox for many years?

Users who have been using Firefox for many years have also been putting up with the aforementioned bugs and unexpected data loss for years. You seem to be operating under the assumption that everyone who's ever used Firefox for a long time is in love with the old quirky behavior of writing files to a special Temp folder before moving them to the Downloads directory.

Clearly, some people (including myself, so PLEASE for the love of God stop trying to convince me) like it. But that's unsurprising because only a minority of users are going to be affected by the errors it caused; and because unexpected data loss is something that will probably only happen a few times before the user puts two and two together and realizes that choosing "Open" causes the file to be vulnerable to deletion.

Yes, but the point is: We aren’t exactly talking about downloaded files. And as I understood comments here, other browsers only offer downloading, not opening.

Google Chrome (overwhelmingly the browser with the most influence on user expectations) offers essentially the same thing Firefox currently does, but in a horizontal bar instead of a panel. Chrome's downloads UI actually improves on Firefox in precisely this way: Instead of merely saying "Open," it says something like "Open when done" while the download is still writing. I can't remember the exact current string but that's the gist of it.

And if they do, they clearly state the file being downloaded, maybe even ask where to.

Firefox clearly states the file is being downloaded too? When you open a hosted file in a web viewer, the downloads toolbar button doesn't animate or flash blue. The downloads panel doesn't open. A download element doesn't appear in the downloads panel corresponding to the file. Instead, every visual indication is given that it's just a simple web page like any other. The whole flow is completely different when the content type specifies an actual download.

There can’t be any direct comparison of Firefox’s behaviour with that of other browsers.

Firefox's current behavior is basically identical to Google Chrome's. Firefox's old behavior was basically identical to Internet Explorer's. What I've been talking about for like 2 weeks now is a user preference that will let the user choose between either model, with Google Chrome's as the default — since it's the least likely to cause download failure or unexpected data loss, and it doesn't break the entire Downloads system in snap/flatpak builds. Frankly, that's the only option now, since Firefox Snap is now the default browser on Ubuntu.

I think, you are overlooking one widespread case: Users with little technical expertise may not even be aware of the fact that a file has to be downloaded before it can be opened. And if the browser asks open or save, they very likely will think of this as XOR.

I'm definitely not overlooking that, because I have responded to that argument twice already in the comments above. Insofar as the "Open" or "Save" argument is misleading about the nature of the "Open" action, that's an argument for changing the string to something like Chrome's "Open when done." The reason that hasn't been done already is because it requires the unknown content type dialog to listen to the download saver and update the string from "Open when done" to "Open" (and ostensibly update the other string from "Save" to "Do nothing") when it stops writing.

Another argument against would be that "Open" is just much more concise. If it's genuinely misleading then it would be worth changing the name of the action. But I think some doubt that it's misleading enough to justify the change, because the dialog clearly says "What should Firefox do with this file?" I think most people understand "file" to mean something saved on your filesystem.

Given what I said above, I don’t think eventually deleting opened files is a serious problem for usability, or for data safety. I think, that is too technical a view.

What on Earth are you talking about? "Eventually"? Firefox deletes them when it exits or crashes, Windows deletes them when it reboots (possibly when user logs out?), and as we've heard from putr4.s, some Linux distros host them on a ramdisk, so they will be invariably deleted if the system merely hibernates. Deleting your tax returns spontaneously, without any visual indication, is not a "serious problem"? I was trying to advocate for a pref to reimplement the Temp behavior months ago (see bug 1709129), because I myself use it. It's not like this use case is foreign to me. I just understand the factors on both sides of the issue, which is exactly why it needs to be a preference and, in turn, why this is so complicated.

At the same time, some users have grown accustomed to their files being automatically deleted by the "Open" download flow, enough to find this so useful that its removal is a disaster. How should their interests be weighed against the interests of new or less knowledgeable users who are not expecting files to be deleted?

That is a point of view that should be thoroughly scrutinised!

It already has been, at great length, across like 30 bug threads (including this one)...

I don’t know anything about flatpak/snap

So maybe you should withhold judgment until you can inform yourself?

but it seems to be more of a flatpak/snap issue. Maybe you have to tell them “sorry, with snap/flatpak this feature cannot be implemented as of today” somewhere in the UI/prefs. This doesn’t look like it should be considered Firefox’s fault.

Like I said before, Firefox Snap is the system default on Ubuntu now. It's working exactly as advertised. It's not that "this feature" can't be implemented in snap or flatpak builds. It's that it will cause downloads to fail on snap/flatpak builds. I think it would probably also break the Windows builds of Firefox Portable, though I haven't tested it. As far as I'm aware, there isn't any special logic for identifying a snap/flatpak pedigree from the app code (like the external helper app service), as there is for distinguishing between the OS env vars.

Could you elaborate on what exactly is the issue here (see above)? When you say boot volume, do you mean the partition from which Firefox is running, or the one on which the user profile is saved, or actually the boot partition?

I think I have adequately explained this, both earlier in this comment and in other comments above. When I say boot volume, I mean the volume on which the operating system is stored. Firefox doesn't care which volume it's running on. The Firefox binary could be located in D:/ but it would still use the boot volume on Windows, since that's where the users directory is located. As for Linux, it depends on innumerable factors, since Linux installers usually allow choosing an arbitrary number of initial system folders, choosing whether they should be folders or partitions or even volumes on separate media.

Consequently, Linux will always have more problems with Downloads, for as long as the current architecture exists: it's a problem if part files are first written in a static location (whether that location is defined by user preference, as in ~/Downloads, or by the OS, as in /tmp or ~/Temp) and then constituted in a "final destination" that could be different from the initial location. The only way to resolve that problem completely would be to avoid writing the downloaded file at all until the user has specified the final destination. So that's why in previous comments I have mentioned how this problem could only be fully resolved at the expense of round-trip download speed. However, this problem is much less consequential on Windows and on some Linux distros than others.

Well, IIUC the current behavior is the same as it already was on macOS. So, apparently lots of macOS users have been downloading files in Firefox for years without demanding that Firefox delete their files.

Yes, but you do have to admit, that Mac is sort of an entirely different world, don’t you think? ;-) In my perception, people who prefer Mac UI/UX, generally have likings that are very different from those of other users (not weird, just different). Having to work with a Mac all day would be an absolute no-go for me (I have tried). I’d have to find a new job. No exaggeration.

No, I don't think that at all. Darwin is basically a unix system. Aesthetically, macOS is pretty similar to a variety of Linux builds. You seem to be implying that macOS users are less technical than users of other systems. But earlier in this comment, you dismissed my opinions by calling me a "developer" and saying that I must have a "more technical view" than Firefox users. And there are many Firefox developers and Mozilla employees who work on Apple computers. You can't have it both ways, so which is it? Are developers' perspectives too far removed from users' to matter, or are macOS users' perspectives not technical enough to matter?

It's not like the users here and on reddit are being ignored, as if their voices don't matter.

I have to say, it does feel like that.

First of all, if you were being ignored, you would be being ignored. Just look at the size of this comment so far. I have already spent more than an hour of my own personal time responding to your questions and complaints, and many of those questions/complaints are the same ones I already responded to in detail in previous posts.

If you wanna test that, try complaining about exactly the same behavior that's implemented in most other browsers, and see how readily their developers are willing to drop everything they're doing and implement the behavior you want. There's a reason Firefox has thousands of preferences while most other browsers only have less than a hundred. It's because Firefox typically responds to conflicts like this, where one set of users' interests are in direct conflict with those of another set, by adding a preference. That's partially because of Mozilla's design philosophy but moreso because Firefox is developed by many thousands of volunteer contributors who are themselves users.

I really appreciate that effort, too, and I am truely sorry that I have to say that this isn’t a satisfactory replacement. You still have to delete every single file you didn’t want to be saved in the first place. Whether you use a file manager or use the download manager as a file manager, there is still that same additional work to be done. In both cases you have to find the files in a list, select them and then delete them, except a file manager allows me to sort files by timestamp, type etc.

And the solution you're demanding isn't a satisfactory replacement either. Nothing about computers is satisfactory. Using a mouse or a monitor isn't satisfactory for me. I would prefer a USB socket soldered into my brain so I can control my computer at electron speed and view content in the innate resolution of my visual cortex. Unfortunately, there are technical (and safety) considerations to take account of besides my personal wants. Just like my "Delete" menu item is a mere band-aid, a mouse and a monitor is a pale imitation of a USB socket in my brain. But USB sockets in humans' brains were never normal or standard in the first place, so I'm hardly in a position to complain about having to use a mouse and a monitor.

As I've said many times before, the previous behavior was convenient for some users, but that doesn't mean it's standard or mandatory. Just because you've gotten used to not having to delete files, doesn't mean that Firefox should continue to delete files for you, no matter the cost. The old behavior cannot simply be reverted because it causes too many problems, and now it would even break the default browser on Ubuntu.

These simple narratives about the developers vs. the users might be emotionally satisfying for people, in the same way conspiracies about the illuminati are, but they contribute nothing to this conversation. I have been in your position before myself, complaining about changes to Firefox without understanding that there are other interests besides my own.

It's not some simple scenario where Firefox developers are lazy or evil and want to ignore the righteous demands of all the users. Firefox has a huge variety of users with a variety of environments and use cases, and it needs to account for all of them in the most balanced way possible. Like I said before, often that will involve creating preferences.

But Firefox can't just split the browser in half with a preference every time there's a conflict. When a preference is added, it means there are now 2 code paths instead of 1. So all the extremely complex downloads code now needs to be tested twice — once with the first code path, and again with the new code path. And it's not like there's just the one. There are thousands of preferences. The downloads system alone has dozens. So we're talking about the number of code paths geometrically multiplying with every preference.

And every code path requires automated test coverage. Every code path needs to be accounted for when something is updated. Now if I want to change anything, I need to account for all the rippling effects it will have on all the obscure pref environments that many developers will never have even heard of. There are far more prefs in Firefox than any individual developer can know about.

And for the 20th time, I'm not saying that means this whole thing should be disregarded. I'm just saying you folks who are coming here to complain should try to have a little perspective beyond your own and stop acting like there's some simple, obvious fix that the malicious Firefox developers are intentionally ignoring, just because you think it will help your argument.

So, either the file needs to be deleted by a "Delete" affordance rather than by an "Open" affordance, OR Firefox needs to expose some opt-in preference that explains clearly that it turns the "Open" affordance into an "Open and Schedule for Deletion" affordance.

I am sure, not every user considers this a deletion of files. Technically it is, of course, but there isn’t that situation, that you want or don’t want a file to be deleted that you didn’t want to save in the first place.

If you didn't want to save a file then you shouldn't have clicked a download link in the first place?

Same. I don’t think the surprise is as big as it may be looking from a developer’s point of view. To me, this seems to be the main pivot of the controversy. I have the impression that this isn’t being sufficiently considered and thought about.

Again, not a developer; Firefox user since I was 12 years old.

(In reply to Shane Hughes [:aminomancer] from comment #87)

Edit: Instead of adding "Save temporarily and" to all of those strings, we could split the dropdown menulist into sections and add menucaptions that make it clear what the following menuitems do. So for the temp options, the menucaption above them would say Save file temporarily and... and then the options would just say "Save file" or "Open with..." as they currently do. And the menucaption above the non-temp options would say Save permanently and... as you'd expect. So the menupopup would be separated into little semantic groupings to allow the strings to remain pretty short. That way we're not stretching it out beyond the normal width of the menulist column.

This approach seems very technical. I think, you shouldn’t have it say “Save file temporarily and …” and then “Save file”.

If you don't have a better idea then what am I supposed to do with this? Also, obviously it's technical, because the whole feature is technical. The only people who even know what we're talking about are technical. The only way these options could even be accessed is in an obscure corner of about:preferences. A technical option is the only thing that is remotely necessary here, because the only people who are complaining about the status quo are power users. The simple option would be to just leave things as they are right now.

And as for the unknown content type dialog (prompted by choosing "Always ask" in about:preferences), a checkbox could be added to the dialog. The checkbox would either say Save file temporarily or Save file permanently, not sure which is clearer.

They’re not synonymous, are they? As a user I would be wondering what the first means.

Isn't this exactly my other point? So why should we treat any files at all as temporary if most users don't even have a concept of "temporary files"? You've arrived at one of the several justifications for removing the Temp folder behavior in the first place. If you're still not satisfied because you personally have a concept of "temporary files," then you're gonna need to content yourself with a solution that's as "technical" as the concept of a "temporary file" is.

Besides, this is hardly more technical than a pref that's only exposed in about:config, that doesn't offer any information about what it does, that you couldn't even find unless you knew in advance what you were looking for, and that you couldn't find any information on without knowing how to search the source code or waiting for some wiki to write about it.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically.

It didn’t before 98! I think you suspect wrongly, see way above, and what you just quoted from Csaba’s comment.

So what? 1) Before 98, the unknown content type dialog opened instead of the downloads panel. Either way, it's obvious that a download is happening. 2) It doesn't even matter what happened before 98 because we're talking about what someone would expect given the current flow. When you start a download, the flow shows you that a download is happening. It wouldn't matter if previous versions of Firefox didn't adequately convey that information, since now a new download is happening, with a new flow, that is conveying that information. But I don't even agree that previous versions of Firefox didn't adequately convey that information.

It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

From my experience with normal users, I wouldn’t say that it is abundantly clear.

And what experience is that? Having managed a learner experience design consultancy firm for the last 8 years and having taken classes on UXD/usability, I think I'm in a better position to evaluate UI clarity and usability.

You have to notice that little symbol in the first place, than give it some thought, try it, find out what it does, and so on.

No you don't... like I said before, it has a tooltip that says "Show in folder." A tooltip is something that appears when you hover your mouse over something. It doesn't require you to use the button.

How many average users do that? How adventurous do you consider the majority of users?

This is an incredibly basic, elementary part of the downloads panel UI. The downloads panel contains from 1-5 horizontal rows, each row corresponding to a session download. Each row has at most only two affordances: the row itself and the button at the end. These are the primary and secondary affordances. They do different things depending on the context, and those different things are conveyed by the tooltip description under the filename.

This is about as obvious as anything in a UI can possibly be, because it's always visible and it updates the display immediately upon hovering. Even in the most complex scenario where both affordances are available (say, a finished download), there are only 2 affordances. Nothing about that UI requires adventurousness. I would expect the vast, vast majority of users who have downloaded a file in Firefox to have used both the primary and secondary buttons, since they are by far the easiest way to interact with downloaded files.

If you download a file for the first time, there isn't anything else you'd think to do instead. The only other options are to just do nothing with the file you just intentionally downloaded; or to open a separate file manager application, and then go searching for the downloaded file by hand. It seems pretty much unfathomable that a new user would choose to do either of those things than to use the obvious affordances in the popup that just opened automatically when they downloaded a file. But even if I'm completely wrong about the secondary affordance, it's still about 1 million times more discoverable than 1) a preference in about:config would be; or 2) a file in C:/Users/me/AppData/Local/Temp would be.

(…) In that case, there's literally no indication that the file is going to be (…) deleted. (…) That's obviously a recipe for confusion (…) Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file and open it, that's only a presentation issue. (…)

Edit: Oh, I almost forgot. (…) On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

Here, you are circling back to the potential misunderstanding of normal users, and of course, if I choose to save a file somewhere, Firefox or any other software has no right whatsoever to delete it, unless I tell it to do so.

To be clear, Firefox is a program. It doesn't have "rights" in the first place.

But that’s far remote from what we are talking about, which is merely opening a file and then basically forget it (or save it afterwards, but that’s a new situation). I fail to see that big peril of confusion.

If you use rhetorical tricks to redefine the flow, then sure, it's not going to be easy to see the problem. But we're not "merely opening a file and then basically forget it". The user is interacting with a web page, add-on, etc. to download a file. Firefox does everything I just described above to make it clear that a download is happening. The file will ultimately save to the user's downloads directory by default — just like every other major browser does.

Before this point, the user could have gone to about:preferences and manually changed the default action to "Open" or "Always ask," in which case they can choose "Open" on a case-by-case basis. With the old behavior, this would prompt Firefox not to move the file from ~/Temp to the downloads directory. It would also prompt Firefox to add the file to a list of files that should be deleted when Firefox exits. The list will be "expunged" automatically on app exit or even, I believe, upon certain types of crash.

So from the user's point of view, we are not "merely opening a file," we are downloading a file. We're not opening the file at all unless the user has gone out of their way to change the default action. And if the user does change the default action, we're still not "merely opening a file," we're downloading and then opening a file. We also know, even merely by the fact that the user managed to navigate through about:preferences and change the default action for the content type in question, that the user is not some clueless luddite who thinks a computer can open a file in an external program without somehow storing the file.

From Firefox's point of view, with the old Temp folder behavior, we do not "merely...forget it (or save it afterwards)". That's wrong on every level. If anything, merely forgetting it is what Firefox does now. First of all, Firefox does not "save it afterwards," it saves it before. Obviously Firefox can't open the file before it's a file, and it can't be a file until it's saved.

I'd also like to point out that Firefox offers no way to "change your mind" about these files. If you choose "Open" and Firefox puts it in the Temp folder and schedules it for deletion, there's no way to tell Firefox to scratch that, put it somewhere more permanent, and cancel the order to delete the file. If you want to do that, you need to find your way into the Temp folder with a file manager, locate the file (possibly amid thousands of other files, as in my case), and move it elsewhere. That also won't work in the future when we add file tracking, so we'd need to add even more special, one-off logic to avoid deleting files that the user moved.

And we do not merely forget the file either. As I've said many many times now, Firefox doesn't just dump it in the Temp folder and leave it there. It schedules the file for deletion. We delete the file when Firefox exits and potentially if/when it crashes. If that somehow fails, the system deletes it. Even if we didn't delete the file ourselves, it still wouldn't be akin to "just forgetting it," because we'd be "just forgetting it" in a folder that's going to be wiped clean by the system. We're intentionally saving it in a place where we expect it to be deleted, without telling the user that it's going to be deleted. That's like calling a demolition company and asking them to demolish your house, and then "forgetting" that your family is still inside.

As to currently unclear and presentation issue I am not following atm.

The fact that choosing "Open" will save the file, not just open it, is really not a problem in my mind, because it's impossible to open a file in an external program without saving it. But as some users have insinuated that some Firefox users are too ignorant to realize that, and therefore might expect "Open" to somehow magically open the file without saving it, I've offered an additional counterargument: the problem in that case is with the string "Open," not with the behavior.

That supposed problem is simply that Firefox isn't presenting the affordances clearly enough for all users to understand what they're for. So, that would be much more readily resolved by renaming "Open" to "Open after saving" or "Open when done saving" than by reverting the downloads architecture to the old Temp folder behavior, which would cause serious problems including breaking the default browser on Ubuntu.

But as I've said before already, I'm not convinced that it is serious enough to justify changing the string to something that's much less concise and would need to be updated by a download listener. I think the vast majority of computer users understand that you can't open a file without saving it.

Comment 108

[vogu66]

As a short summary for users who don't have the time to read all the stuff before (disclaimer, I'm partial to having temporary downloads):

Users who have the bug are annoyed because:

• The behaviour changed
• Files are saved and it's annoying to sort through the junk files now cluttering downloads
• This bug is marked as "WONTFIX" for some reason

People who are for the change made it because:

• There is a risk of data loss if temporary files are not known to be temporary (think of, you open a file, you modify it, then you save it, but it saved it in the temp folder and is thus deleted when you reboot, I know I lost a few Word files like that when I was newer to computers, so I get it even if I would prefer Firefox to save in /tmp)

Proposed solutions to the problem are:

• Change the strings in the "open" dialog to make them clearer (seems like a dead end, doesn't really please anyone)
• Have a different saving place for opened files (e.g. ~/Downloads/temp) where the user could manually delete everything if they wish to.
• Have a setting to restore the old behaviour (i.e. propose to save new files in ~/Downloads or in temp folder)

Personally I'm a fan of having a checkbox to ask whether I want to save opened files in the same folder as saved files, then if yes choose "temporary folder" or any location on the computer, with a default for normal_location/temp.

Also, if you want to revert the behaviour on your machine for now, you can set browser.download.improvements_to_download_panel to false, if I got that right.

In any case, please do not repeat previous arguments, it is counter-productive to having the bug resolved.

Comment 109

[Shane Hughes [:aminomancer]]

(In reply to Martin from comment #106)

Sorry but you're missing the point. People are angry exactly because now they're forced to keep the files they don't want to keep. They have to actively keep track of files they don't want and delete them, in perpetuity.

Shocking, I had no idea.

I've already explained this in like 3 or 4 of my previous posts, so this is gonna be the last time I do it: Firefox used to write part files in the Temp directory and then move them to the final destination. When the user chose "Open," that last step was basically skipped. Now, Firefox writes part files in the user-specified Downloads directory (set by preference browser.download.dir), and then moves them to the final destination. As before, when the user chooses "Open," the file remains in the Downloads directory.

This isn't how it's worked for me. Since I can remember the part file was always created in the destination directory along with the destination file that is of size 0 until the download is finished. I don't remember it ever working differently. I've just checked on a VM and that's how it works.

Go read the source code.

That is done because downloaded files are not webpages. They cannot just be held in memory. Even webpage resources are not merely held in memory, but are stored on the filesystem in caches. So I said in my previous comment that ANY web browser is going to need to store files on the filesystem no matter what, and that this can't possibly be a "privacy violation" because it's been part of the basic functionality of all web browsers (except maybe Tor browser) for decades.

Firefox goes and puts the file to my download directory behind my back. I don't want this. From the user point of view those are temporary, inconsequential files. I shouldn't be forced to track and delete them all the time. I want to view a pdf in Okular, I don't want to keep the file, I don't want it ever touching my drive. /tmp (of course it's tmpfs, that it needed explaining is strange to me) is a good place to put that file. Other would be the user dir under /run (which too should be backed by tmpfs).

I and others have given several reasons why /tmp and ~/Temp are not good places to save a downloaded file. Like I said many times, the fact that those issues haven't personally affected you is of no consequence, because Firefox has to account for more users than just you (e.g., macOS users, Windows users, users of Ubuntu where Firefox Snap is now the default browser, etc.). That can really only mean a preference. The questions are 1) how Firefox can expose the preference without confusing users; 2) how the preference can avoid the pitfalls of the old Temp download behavior; and 3) if/how the preference can be implemented without bifurcating the entire Downloads system and thereby doubling its development and testing burden.

If we can stop cluttering the thread with petty arguments about privacy violations and personal anecdotes then maybe we can move forward on my user preference proposal. Your constant pedantic lectures about "why people are angry" are hindering more than helping. I already know why people are angry, I have been using the temp folder in this way for many years, and I've already done vastly more than you to resolve this problem. Finally, I've already spent way more time than I should responding to your complaints.

Please look at it from the point of view of the user. People are angry because they are forced to track and delete files they never intended to keep. It's creating a mess in downloads directory and wastes users' time.

I am a user. What is this, Alex Jones versus the Mozilla illuminati? And when I'm donating my own personal time to contribute code to Firefox, I am doing literally nothing else but looking at it from the points of view of users. It turns out there isn't just one person called "the user" who Firefox needs to cater to. Firefox has more than 100 million people with more than 100 million points of view to consider.

In addition to my own point of view as a Windows user who opens lots of files with no intention to use them again, I also need to consider the point of view of someone who will be rightfully angry when Firefox deletes their wedding photos or their tax returns without warning or explanation. (I held off on recommending Firefox to my dad for this exact reason) And I need to consider the point of view of snap and flatpak users (like on Ubuntu now) who will have far more serious problems than the mild nuisance of needing to clean up the files that you chose to download.

Before this was introduced it wasn't a problem at all. Files were put in /tmp and the user didn't have to worry about anything, they hadn't even thought this could be an issue… until Firefox made it an issue.

You don't think maybe you're being a bit hyperbolic here? "wasn't a problem at all"? "Firefox made it an issue"? Really? The only reason a user didn't have to worry about anything is because they knew files were put in /tmp. But how would they have known? Only by their own discovery. It's not like Firefox tells you "Save in /tmp and open" or something. So on the one hand, you didn't have to worry about anything because you knew not to use that option unless you wanted the file to be deleted.

On the other hand, other users didn't have to worry about anything because they didn't have any idea the file would be deleted in the first place. You can't worry about that which you're unaware of. Until you notice that one of the files in your Downloads library is gone, without explanation. Firefox deleted it, but there's no way to know that after the fact. God only knows how many users lost data like this but never submitted feedback because they had no way to know (let alone to prove) that Firefox was the cause.

Before the changes this was definitely a problem. Now we have a different problem. Maybe there's a way to resolve both problems, but it's not gonna involve denying the former problem.

This is gonna be my last reply, I can't keep repeating myself for people who don't bother to just read the previous comments above. If anyone else is thinking of posting to share their outrage, first ask yourself if the 100+ comments above haven't already covered that ground.

Comment 110

[Shane Hughes [:aminomancer]]

(In reply to vogu66 from comment #108)

• This bug is marked as "WONTFIX" for some reason

It's marked as wontfix because this was originally marked as a regression, not an enhancement request. It seemed to presume that this was accidental. Then it was changed to an enhancement request, but reverting Firefox back to the old behavior is basically ruled out. See comment #8 by Romain:

Overall users will find it easier to discover downloaded files in the "Downloads" directory, this aligns with behavior from other browsers and I'm not seeing concerns that are not address with Gijs comments apart from the need for an API on Comment 5.
I'll close this bug and recommend filing a specific bug for an API request on https://bugzilla.mozilla.org/enter_bug.cgi?product=WebExtensions.

...and several other comments near the top. So it's unlikely that this will be resolved by further comments here. Romain has already suggested that you file an API request instead so that an add-on can be made that meets the demand. I've shared my user pref ideas already, but there's only a small chance that they will be approved. The chance is reduced even further if nobody can find my comments, crowded out as they are by angry manifestos about developers conspiring to ruin Firefox. These kinds of constant email notifications that lead only to hostility will also cause Mozilla employees to remove themselves from the CC list.

People who are for the change made it because:

• There is a risk of data loss if temporary files are not known to be temporary (think of, you open a file, you modify it, then you save it, but it saved it in the temp folder and is thus deleted when you reboot, I know I lost a few Word files like that when I was newer to computers, so I get it even if I would prefer Firefox to save in /tmp)

This isn't an adequate summary of the issues. There are many more problems with saving files in the Temp folder, especially with the way it is implemented currently.

1. Yes, there is a risk of data loss, not due to user ignorance or stupidity, but because Firefox offers literally no indication that choosing "Open" is going to cause the file to be automatically deleted at some indeterminate time in the future. It's not a failure on the part of users that they don't expect Firefox to idiosyncratically save files in the Temp folder instead of the Downloads folder, and schedule those files for deletion.
2. There's a risk of failure near the end of a download when the content is transferred to the final destination file if the final destination (the user's chosen downloads directory) is on a different volume than the Temp folder and that volume has less storage space than necessary.
3. Firefox also lacks permission to use /tmp in some environments. Since the old behavior (the one currently permitted by disabling the improvements pref) involves writing part files in /tmp before transferring the content to the ultimate destination, this will cause the downloads system to totally break. As I mentioned in previous posts, this affects Firefox versions installed by Snap and flatpak. And now, Firefox Snap is the default browser on Ubuntu, so this isn't just trivia.
4. As Romain's post mentioned, the ~/Downloads directory is much more discoverable than C:/Users/you/AppData/Local/Temp.
5. Saving downloads in 2 different locations is confusing, especially when the affordances that actually choose between them don't give any indication that the user is choosing a final location.
6. Saving downloads in the Temp folder means that Firefox ignores the user's preference for download location, which is otherwise used. This is fine if the affordance explicitly says that, but it doesn't say that. It just says "Open"
7. Most other major browsers don't save files in the Temp folder. It's not like that's an incontrovertible reason to close this issue, but it shows that there is no standard expectation for this behavior. The other problems I mentioned help to explain why other browsers do not do this.
8. Proposals for a user preference or a WebExtensions API could resolve the issue without provoking all the above issues. However...
9. As Gijs mentioned in comment #3, adding a preference to maintain the old behavior will mean "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)."

Personally I'm a fan of having a checkbox to ask whether I want to save opened files in the same folder as saved files, then if yes choose "temporary folder" or any location on the computer, with a default for normal_location/temp.

That would probably be the simplest way to present the option to the user, but it would demand a huge additional lump of testing coverage. It would mean not just doubling the number of flows (that need to be covered by automated tests and accounted for with every future update to the Downloads system) but actually tripling it. That's why this is very discouraging and I expect why not many contributors are posting.

Also, if you want to revert the behaviour on your machine for now, you can set browser.download.improvements_to_download_panel to false, if I got that right.

That's correct, but to be clear, this pref will be removed eventually. Maintaining it requires a lot of additional clutter that slows down development (and technically, execution too), especially given the sheer number of times it needs to be checked in the process of just a normal download interaction.

Comment 111

[Dalacor]

Is it not possible to hold and moderate comments for review before they get published. I am in full agreement that people are now just spamming the thread repeating what everyone else has already said and even worse arguing about what the definition of a temporary file is.

I fully support the developers in that the focus should be on implementing a solution that works for everyone. So can people please stop spamming the thread with information that has already been said a dozen times over in this thread.

Solution One

My original suggestion of having a Firefox View and Firefox Download sub folders in the downloads folder still stands. Not the prettiest hack, but is workable.

Solution Two

Another suggestion would be to have anything explicitly saved go to the downloads folder (so this would be the same pre and post version 98) and anything explicitly opened be saved to a Firefox View sub folder within the C:\Users\Username\Apddata\Roaming\Mozilla\Firefox\Profiles\profile-folder. So the first change pre/post 98 would be to move the location of the opened files from Temp to the Mozilla Firefox Profile folder. Yes I understand that Mozilla are not keen on the two folder concept, but I believe that their concerns can be addressed in a different way.

Then on the Firefox Privacy Page have options to auto delete anything in that folder after a time period (which can be set by the user). I would do mine at 3 months. But this can be disabled by default. This means for non power users - all files are retained - regardless of whether downloaded or opened (in the eyes of the user). But for Power Users like myself, enabling and setting auto delete these files from that subfolder within the Mozilla Firefox Profile solves our biggest problem which is getting rid of files we don't want to keep and secondly - keeping it out of the downloads folder where it does not go. Also having a time period of say three months to clear out that folder I presume would also solve the problem of files to be opened not downloading properly?

Then my third suggestion - for addressing Mozilla's concerns about power users being unable to find their saved files, would be to split the Firefox Download Manager into two and call it Firefox File Manager and tab one could be for Saved files - aka Downloads folder and tab two could be viewed/opened files aka Firefox View folder within the Mozilla Firefox Profile. With the ability within the Firefox File Manager to move files from either location to a new location. Don't rely on non technical users to know where the downloads and Firefox View folders are using Windows explorer. Rather handle this for them within Firefox File Manager and the end user doesn't need to know where the files are actually saved! Let Firefox File Manager be the explorer view for both locations and for handling files downloaded/opened by Firefox!

I have no complaints moving the opened files from the temp folder to a new location - I think it is a good idea.
I have no complaints with the approach to making it easy for non technical users to find all their documents whether explicitly downloaded or simply opened - I think it is a good idea.
I have no complaints with defaulting to storing all files on the hard drive (whether in downloads/temp or downloads/Firefox View in Mozilla Profile) - I think it is a good idea.

I believe that the above goals can be addressed by either solution one or solution two. My preference would be for solution two as it's not a hack and has the major advantage in that the default settings and Firefox File Manager will work well for non technical users, remove files not explicitly downloaded by the user from the downloads folder and giving power users the ability to auto delete files that are just opened.

Comment 112

[rsbrux]

(In reply to :Gijs (he/him) from comment #65)

(In reply to rsbrux from comment #64)

My confusion comes from the fact that the setting "Always ask you where to save files" under "Downloads" now appears to be overridden by any settings "Save file" under "Applications". Before v98, I had all PDF types set to "Save file", but the setting "Always ask you where to save files" ensured that I would always be prompted where to save them. Since 98, I am forced to change all of the individual application settings (of which there are many) from "Save file" to "Always ask". Why has the relative priority of these settings changed?

It shouldn't have changed. It sounds like you're seeing a bug, which either way is unrelated to this one (which is about whether we use the temp folder for files that are opened, whereas the issue you describe appears to be about files that you are deliberately saving, rather than opening). Please file a separate issue with more details about your setup -- if I try to do the same thing you're describing, based on your description alone, I get the results you want without changing any application settings to "always ask", so we'd need to investigate why you're seeing something else, and this bug is not the right place to do that.

Indeed, I originally posted this as a separate bug, but it was subsequently deemed to be a duplicate of this one. I have meanwhile adjusted Firefox to suit my needs and don't feel like trying to reproduce the reported behaviour.
Thanks for your support!

Comment 113

[Shane Hughes [:aminomancer]]

(In reply to Dalacor from comment #111)

Also having a time period of say three months to clear out that folder I presume would also solve the problem of files to be opened not downloading properly?

Actually, the problem with download failures wasn't a result of the files being deleted, but just a result of the download's final destination being on a different volume than the Temp folder, which would have different amounts of unused storage capacity. So it doesn't really bear on this issue.

Under the hood, this proposal would involve starting download writes in the ~/Downloads folder, as any other download is written in part files. And then, when it's clear that the "Open with x" action has been chosen instead of "Save," Firefox would have to move the data from ~/Downloads to .../{profile}/opened downloads. Or, the reverse could be done, where downloads are initially written to .../{profile}/opened downloads, and then downloads that are not "Opened with x" would be moved to ~/Downloads.

I think solution 2 is pretty solid. I'm not sure whether it would be better for such a folder to go in the Local profile folder (with the file caches) or in the Roaming profile folder (with user preferences) — there are merits to both. Unfortunately there's still the potential for downloads to fail with this system, because ~/Downloads isn't necessarily on the same volume as the user's Firefox profile. So although I think it looks kinda janky, solution 1 is probably the best so far in that it doesn't involve any cross-volume transfer (except when using "Save as" but that's unavoidable, even with the current status quo).

Unfortunately none of the solutions proposed so far would solve probably the biggest issue with adding a preference: the sheer amount of testing and development burden it would constitute. I've described in previous posts how a pref that affects so many things like this will basically split Firefox in half so that there are 2 different configurations to develop for and test. Having written some test files myself I can say it's often much more time-consuming and frustrating than writing the actual code.

Comment 114

[Adrian]

If you had read any of my comments you would know I do not think that.

While quoting what was probably your comment to start my reply, with "you" I mainly meant "Mozilla" as a whole, not you personally. And I did read all comments a few days ago but honestly, it was late, the thread is huge, so I may have skimmed some parts or missed things...

I think 1759779 is a great step in the right direction; I'll leave some suggestions/ideas on this bug in order to not add even more to this humongous bug.

Comment 115

[Dalacor]

(In reply to Shane Hughes [:aminomancer] from comment #113)

Actually, the problem with download failures wasn't a result of the files being deleted, but just a result of the download's final destination being on a different volume than the Temp folder, which would have different amounts of unused storage capacity. So it doesn't really bear on this issue.

Fair enough. I don't know the issues surrounding the temp folder problems.

Under the hood, this proposal would involve starting download writes in the ~/Downloads folder, as any other download is written in part files. And then, when it's clear that the "Open with x" action has been chosen instead of "Save," Firefox would have to move the data from ~/Downloads to .../{profile}/opened downloads. Or, the reverse could be done, where downloads are initially written to .../{profile}/opened downloads, and then downloads that are not "Opened with x" would be moved to ~/Downloads.

I personally would go down the route of saving to the temp location first and if the user wants to keep the file, then move it to the downloads folder. This is what Firefox has been doing for years anyway - saving to the temp folder and then moving it to the downloads folder. This means if files get corrupted etc, they are not showing up in the downloads folder.

I think solution 2 is pretty solid. I'm not sure whether it would be better for such a folder to go in the Local profile folder (with the file caches) or in the Roaming profile folder (with user preferences) — there are merits to both. Unfortunately there's still the potential for downloads to fail with this system, because ~/Downloads isn't necessarily on the same volume as the user's Firefox profile. So although I think it looks kinda janky, solution 1 is probably the best so far in that it doesn't involve any cross-volume transfer (except when using "Save as" but that's unavoidable, even with the current status quo).

I would recommend the roaming profile as most people (myself included) know to copy the mozilla folder in the roaming folder from one PC to another PC. I have never backed up or transferred the Mozilla folder in the Local profile. So people would just lose data if their viewed files were in the local profile instead of the roaming profile. If there is actual data, it should be in the roaming profile location as that is what people backup when moving to a new PC.

Perhaps Firefox could have a warning feature built in advising users of potential data loss if downloads and Mozilla Profile are not on the same volume? Or use telemetry to see how many users would actually be affected. The temp folder I can understand being on a different volume, but the likelihood of a user's download folder and mozilla profile being on different volumes is very low. I don't have any answer to this particular problem.

Unfortunately none of the solutions proposed so far would solve probably the biggest issue with adding a preference: the sheer amount of testing and development burden it would constitute. I've described in previous posts how a pref that affects so many things like this will basically split Firefox in half so that there are 2 different configurations to develop for and test. Having written some test files myself I can say it's often much more time-consuming and frustrating than writing the actual code.

I don't really know what is involved here especially as Firefox for years has had the options always ask, always save, always open, but my suggestion of an auto delete option for viewed files isn't really essential if these files are not being saved to the downloads folder. If we could essentially just move these files from the temp files folder to the mozilla profile or subfolder of downloads then a new preference is not required. The chief requirement is to get the viewed files out of the main downloads folder. The auto delete prefs would be a nice feature, but not essential. Perhaps step one should be just focusing on relocating the saved location of the files that are opened to avoid clogging up the downloads folder as this is the main complaint. For those users who want to delete files from that folder, we could easily script that ourselves or users could go in once every couple of months and manually clear that folder. It is not essential that Firefox handle the auto deletion if this helps to avoid adding preferences.

Comment 116

[lrdix]

(In reply to Shane Hughes [:aminomancer])
I, too, invested many hours in trying to make you (Mozilla) understand possible (and existing!) users’ views on Firefox. I really tried to make my comments not sound hostile or aggressive, but either I failed or you decided to regardlessly stop your own efforts in that respect. A few last answers from my side:

(In reply to Shane Hughes [:aminomancer] from comment #107)

You seem to be operating under the assumption that everyone who's ever used Firefox for a long time is in love with the old quirky behavior of writing files to a special Temp folder before moving them to the Downloads directory.

No, you obviously didn’t read my post carefully enough.

Google Chrome (…): Instead of merely saying "Open," it says something like "Open when done" while the download is still writing. I can't remember the exact current string but that's the gist of it.

Which is why it surprises the user with files being still around way less than Firefox 98+. Privacy issue in Firefox.

I'm definitely not overlooking that, because I have responded to that argument twice already in the comments above. Insofar as the "Open" or "Save" argument is misleading about the nature of the "Open" action, that's an argument for changing the string to something like Chrome's "Open when done." The reason that hasn't been done already is because it requires the unknown content type dialog to listen to the download saver and update the string from "Open when done" to "Open" (and ostensibly update the other string from "Save" to "Do nothing") when it stops writing.

Another argument against would be that "Open" is just much more concise. If it's genuinely misleading then it would be worth changing the name of the action. But I think some doubt that it's misleading enough to justify the change, because the dialog clearly says "What should Firefox do with this file?" I think most people understand "file" to mean something saved on your filesystem.

I think you are wrong here. And you really can’t be serious with that last sentence.

Deleting your tax returns spontaneously, without any visual indication, is not a "serious problem"?

I am not sure what you mean here, but if it is a PDF I can just download again, no, not serious.

You seem to be implying that macOS users are less technical than users of other systems.

I am defintively not.

And there are many Firefox developers and Mozilla employees who work on Apple computers.

There we have it! Maybe that’s the root of the problem.

Are developers' perspectives too far removed from users' to matter,

Too far removed to understand users, obviously.

or are macOS users' perspectives not technical enough to matter?

I didn’t say that.

This approach seems very technical. I think, you shouldn’t have it say “Save file temporarily and …” and then “Save file”.

If you don't have a better idea then what am I supposed to do with this?

Notice that it’s contradictory to first say save temporarily and then save.

And as for the unknown content type dialog (prompted by choosing "Always ask" in about:preferences), a checkbox could be added to the dialog. The checkbox would either say Save file temporarily or Save file permanently, not sure which is clearer.

They’re not synonymous, are they? As a user I would be wondering what the first means.

Isn't this exactly my other point? So why should we treat any files at all as temporary if most users don't even have a concept of "temporary files"? You've arrived at one of the several justifications for removing the Temp folder behavior in the first place. If you're still not satisfied because you personally have a concept of "temporary files," then you're gonna need to content yourself with a solution that's as "technical" as the concept of a "temporary file" is.

Seriously? How can you make this out of what I wrote?

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically.

It didn’t before 98! I think you suspect wrongly, see way above, and what you just quoted from Csaba’s comment.

So what? 1) Before 98, the unknown content type dialog opened instead of the downloads panel. Either way, it's obvious that a download is happening.

No.

2. It doesn't even matter what happened before 98 because we're talking about what someone would expect given the current flow.

No, what long-term users are used to influences what they expect. And that has nothing to do with 98, when it is brand new.

When you start a download, the flow shows you that a download is happening. It wouldn't matter if previous versions of Firefox didn't adequately convey that information, since now a new download is happening, with a new flow, that is conveying that information.

It obviously isn’t, or how would you explain that many users were surprised when they noticed old files still being in the downloads folder?

It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

From my experience with normal users, I wouldn’t say that it is abundantly clear.

And what experience is that? Having managed a learner experience design consultancy firm for the last 8 years and having taken classes on UXD/usability, I think I'm in a better position to evaluate UI clarity and usability.

Well, that and the fact that you are contributing to Firefox makes you much more of developer than any other user. You certainly have a much more technical and developer driven view than mere users.

You have to notice that little symbol in the first place, than give it some thought, try it, find out what it does, and so on.

No you don't... like I said before, it has a tooltip that says "Show in folder." A tooltip is something that appears when you hover your mouse over something. It doesn't require you to use the button.

Are you kidding me? It doesn’t require me to click on it, but I still have to move the pointer there, wait for the tooltip, read it, think about it. And you are telling me you don’t have a view on things, that is significantly more technical than that of other users?

How many average users do that? How adventurous do you consider the majority of users?

This is an incredibly basic, elementary part of the downloads panel UI. The downloads panel contains from 1-5 horizontal rows, each row corresponding to a session download. Each row has at most only two affordances: the row itself and the button at the end. These are the primary and secondary affordances. They do different things depending on the context, and those different things are conveyed by the tooltip description under the filename.

This is about as obvious as anything in a UI can possibly be, because it's always visible and it updates the display immediately upon hovering. Even in the most complex scenario where both affordances are available (say, a finished download), there are only 2 affordances. Nothing about that UI requires adventurousness. I would expect the vast, vast majority of users who have downloaded a file in Firefox to have used both the primary and secondary buttons, since they are by far the easiest way to interact with downloaded files.

That is what I mean when I say technical view. You already have moved a great deal towards being a developer, an expert, and are to a certain degree unable to comprehend a normal user’s approach to the usage of Firefox. A normal user is highly unlikely to look out for that new (Is it? See below.), tiny symbol and going like “Oh, cool, maybe it allows me to delete the files I haven’t noticed being permanently saved for a while.”

If you download a file for the first time, there isn't anything else you'd think to do instead. The only other options are to just do nothing with the file you just intentionally downloaded; or to open a separate file manager application, and then go searching for the downloaded file by hand. It seems pretty much unfathomable that a new user would choose to do either of those things than to use the obvious affordances in the popup that just opened automatically when they downloaded a file.

Unfathomable? Really? To use a file manager, when you have one, and consider it the most basic software tool when working with an OS with GUI?

But even if I'm completely wrong about the secondary affordance, it's still about 1 million times more discoverable than 1) a preference in about:config would be; or 2) a file in C:/Users/me/AppData/Local/Temp would be.

No. You said only readers of this thread and people going through the code would discover the pref in about:config. That’s wrong. There would be like a quintillion articles all over the web, like there are know because of this many other changes. Anyone using a search engine would read about it. I would never be looking for that symbol when I had to delete a file. Apart from that, to me, that symbol doesn’t indicate I can delete a file with it, because I know that symbol from before 98, where it allowed me to open the folder containing the file. And again, first choice for that task is a file manager.

But that’s far remote from what we are talking about, which is merely opening a file and then basically forget it (or save it afterwards, but that’s a new situation). I fail to see that big peril of confusion.

If you use rhetorical tricks to redefine the flow, then sure, it's not going to be easy to see the problem.

Say what?!

Here, you are circling back to the potential misunderstanding of normal users, and of course, if I choose to save a file somewhere, Firefox or any other software has no right whatsoever to delete it, unless I tell it to do so.

To be clear, Firefox is a program. It doesn't have "rights" in the first place.

How’s that for a rhetorical trick?

But we're not "merely opening a file and then basically forget it". The user is interacting with a web page, add-on, etc. to download a file.

Or open it outside Firefox, view it, save it in a certain directory or not save it, close it, forget it.

Firefox does everything I just described above to make it clear that a download is happening. The file will ultimately save to the user's downloads directory by default — just like every other major browser does.

No. It doesn’t tell you that, when you choose to open the file, unlike other browsers. So, whatever Firefox is doing, it’s not enough. People were very surprised, that’s an empirical fact you’ll just have to accept.

We're not opening the file at all unless the user has gone out of their way to change the default action.

Come on, you do know that’s the main case we are talking about. Why do you have to harp on about some other cases, where defaults are still in place? Technical end of the thinking spectrum.

We also know, even merely by the fact that the user managed to navigate through about:preferences and change the default action for the content type in question, that the user is not some clueless luddite who thinks a computer can open a file in an external program without somehow storing the file.

That certainly is a fatal misconception.

If anything, merely forgetting it is what Firefox does now. First of all, Firefox does not "save it afterwards," it saves it before. Obviously Firefox can't open the file before it's a file, and it can't be a file until it's saved.

That’s a hair-splitting inanity. Try to think like a user, who never saw one line of source code.

I'd also like to point out that Firefox offers no way to "change your mind" about these files. If you choose "Open" and Firefox puts it in the Temp folder and schedules it for deletion, there's no way to tell Firefox to scratch that, put it somewhere more permanent, and cancel the order to delete the file.

Cool.

If you want to do that, you need to find your way into the Temp folder with a file manager, locate the file (possibly amid thousands of other files, as in my case), and move it elsewhere.

Or just download the file for a second time.

That also won't work in the future when we add file tracking, so we'd need to add even more special, one-off logic to avoid deleting files that the user moved.

Is it really that difficult no to program Firefox in a way that it doesn’t delete files the user actually deliberatly saved somewhere with the intention to keep them permanently?

And we do not merely forget the file either. As I've said many many times now, Firefox doesn't just dump it in the Temp folder and leave it there. It schedules the file for deletion. (…)

I didn’t say you, who write the code, are forgetting. The user is.

That's like calling a demolition company and asking them to demolish your house, and then "forgetting" that your family is still inside.

I actually don’t know what to say to this, without being insulting.

As to currently unclear and presentation issue I am not following atm.

The fact that choosing "Open" will save the file, not just open it, is really not a problem in my mind, because it's impossible to open a file in an external program without saving it. But as some users have insinuated that some Firefox users are too ignorant to realize that, and therefore might expect "Open" to somehow magically open the file without saving it, I've offered an additional counterargument: the problem in that case is with the string "Open," not with the behavior.

Maybe go for a walk? Even stop working on this for a week or two? It really looks to me like your mind is fogged by this discussion. The user isn’t ignorant, the user simply doesn’t know. The problem is with the combination of the string and the behaviour. Either stick with “Open” and the old behaviour, or call it “Download and open” with the new behaviour. I bet most users are long-term users. Long-term users have been surprised, and in a very negative way. That’s a fact.

That supposed problem is simply that Firefox isn't presenting the affordances clearly enough for all users to understand what they're for. So, that would be much more readily resolved by renaming "Open" to "Open after saving" or "Open when done saving" than by reverting the downloads architecture to the old Temp folder behavior, which would cause serious problems including breaking the default browser on Ubuntu.

But as I've said before already, I'm not convinced that it is serious enough to justify changing the string to something that's much less concise and would need to be updated by a download listener. I think the vast majority of computer users understand that you can't open a file without saving it.

Well, you seem to understand it and not understand it at the same time. In the end: It is justified. The problem isn’t even with users knowing or not knowing that you can’t open a file without saving it. See above.

(In reply to Shane Hughes [:aminomancer] from comment #110)

This isn't an adequate summary of the issues. There are many more problems with saving files in the Temp folder, especially with the way it is implemented currently.

1. Yes, there is a risk of data loss, not due to user ignorance or stupidity, but because Firefox offers literally no indication that choosing "Open" is going to cause the file to be automatically deleted at some indeterminate time in the future. It's not a failure on the part of users that they don't expect Firefox to idiosyncratically save files in the Temp folder instead of the Downloads folder, and schedule those files for deletion.

Wrong assumption.

2. There's a risk of failure near the end of a download when the content is transferred to the final destination file if the final destination (the user's chosen downloads directory) is on a different volume than the Temp folder and that volume has less storage space than necessary.

Once in every blue moon. And why is it Friefox’s fault, when the user’s drives are full?

4. As Romain's post mentioned, the ~/Downloads directory is much more discoverable than C:/Users/you/AppData/Local/Temp.

How can you blame others for repeating the same old arguments? Who wants to discover a file he doesn’t want and expect to be anywhere on his machine or network?

5. Saving downloads in 2 different locations is confusing, especially when the affordances that actually choose between them don't give any indication that the user is choosing a final location.

What other location could he possibly be choosing?!

6. Saving downloads in the Temp folder means that Firefox ignores the user's preference for download location, which is otherwise used. This is fine if the affordance explicitly says that, but it doesn't say that. It just says "Open"

So? Three more words somewhere? Sounds like the easiest patch or fix ever.

Comment 117

[luca.dgh]

Well, I opened a ticket for this bug, they closed it because duplicate so I wrote my disappointment in the other ticket. Now I found this ticket and I see that Firefox is not going to revert this terrible feature. As I said in the other tickets I daily open hundreds of files from the web and I download 1% of them, it's terrible for me to look for the desired file in the huge trash that generates Firefox.
I wonder if the users opinions means something to you and actually I don't understand your reasons of maintenance costs (Gijs), but I ask: "Do you really want that yours users migrate to another browser?"
It's hard for me to understand this stubborn attitude.

Comment 118

[:Gijs (he/him)]

I didn't want it to get to this point but the discussion here has ceased to be productive, and I'm going to restrict comments, at least for the moment.

Folks at Mozilla are aware of the strength of feeling around this behaviour and we'll go over the comments and evaluate whether we need to reconsider in the coming week(s). The bug is going to stay closed at least until that has happened. In the meantime, I'm going to point to the etiquette guidelines and ask that people do not file duplicates just to continue the discussion (they will just be closed and doing so will waste time of folks who could be writing patches to address some of your feedback), and in any other related issues, to assume good faith on all concerned, especially when it comes to non-employees who have volunteered time to contribute patches to help address some of the same issues folks here are unhappy about. Y'all wanna blame me, fine (if inaccurate) - but don't take it out on the folks trying to help you out.

Comment 127

[Romain Testard [:RT]]

A number of product and engineering folks met to discuss the feedback here.
Based on that feedback, we will add an about:config option and an enterprise policy that will reenable the use of (a subfolder of) the temp folder when downloads start. We considered a number of other options, such as subfolders in the main downloads directory, automatically deleting files, moving files from the downloads folder into temp for opened files only, and others, but each of those options has its own downsides, and none would address all of the feedback here (for instance, using subfolders or auto-deletion would not address performance concerns around download locations on network shares).
This new option will be opt-in. We do not intend to revert to the previous default behaviour. Because of the downsides inherent in the use of the temp folder, we believe that the new default is better for new users as well as the majority of existing users. People who choose to change this preference or enterprise policy should be aware of those downsides and make a considered decision.
As an administrative note, we are reopening this bug because we will need it to facilitate implementing this new option, but we will not reopen comments/discussion on this bug, as it would distract from that work.

Comment 129

[:Gijs (he/him)]

Attachment: Bug 1738574 - add an option to put downloads in tmp to start with, r?mak!,mtigley!,mkaply!

Comment 131

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3c9653131b8f
add an option to put downloads in tmp to start with, r=mak,mkaply,fluent-reviewers,flod

Comment 132

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/3c9653131b8f

Comment 133

[:Gijs (he/him)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Number of requests after Fx99
[Affects Firefox for Android]: No
[Suggested wording]: There is now an enterprise policy (StartDownloadsInTempDirectory) and an about:config pref (browser.downloads.start_downloads_in_tmp_dir) that will once again cause Firefox to initially put downloads in (a subfolder of) the OS temp folder, instead of the download folder configured in Firefox. Files opened from the "what should Firefox do with this file" dialog, or set to open in helper applications automatically, will stay in this folder. Files saved (not opened as previously mentioned) will still end up in the Firefox download folder.
[Links (documentation, blog post, etc)]: none so far.

Some other notes for folks CC'd here:

• to be clear, assuming it doesn't get backed out this will be in tomorrow's Firefox 102 nightly build, and it will hit beta next week, and "regular" Firefox release in about a month.
• it isn't possible to uplift this to 101 because (a) it contains localization changes, (b) 101 release candidates have already been built (release day is a week away) and (c) there is some risk here and it should have some baking time on nightly+beta.
• as extensively discussed here and elsewhere, including bug 69938, there are downsides to flipping this pref; use at your own risk, yada yada yada
• if you report bugs with this old-and-now-new behaviour, please be clear about the specific issue you're seeing, what prefs you have flipped (including this one), OS, whether you're using a snap build (NB: I expect it to go back to the weird special-snap-folder but ymmv; I wasn't in a position to test this), the contents of handlers.json, and an example (publicly accessible) download link that reproduces the issue (if the download link isn't public, please provide the server headers from the file, obtained via the browser console, browser devtools network monitor, or other network inspection)
• downloads will also go back to being deleted after being opened (when Firefox shuts down) with this pref flipped, on non-macOS. This is separately configurable via browser.helperApps.deleteTempFileOnExit (a pre-existing pref). That pref doesn't affect downloads unless you also flip the start_downloads_in_tmp_dir one
• automatically-opened (or opened-from-the-"what should Firefox do with this file"-dialog) private browsing downloads continue to be deleted when the private browsing session finishes irrespective of either pref.
• the browser.download.improvements_to_download_panel will stop influencing the download destination behaviour, but...
• if you've previously flipped the browser.download.improvements_to_download_panel pref to false, Firefox will automatically set the new pref for you (ie you shouldn't see a change to the destination used)

Comment 134

[Pascal Chevrel:pascalc (PTO until April 26)]

Note added to 102 nightly notes

Comment 135

[Tom S [:evilpie]]

I think there is some kind of mistake here. StaticPrefList.yaml calls this pref browser.download.start_downloads_in_tmp_dir, but Policies.jsm uses browser.download*s*.start_downloads_in_tmp_dir. The release page also has the s.

Comment 136

[:Gijs (he/him)]

(In reply to Tom Schuster [:evilpie] from comment #135)

I think there is some kind of mistake here. StaticPrefList.yaml calls this pref browser.download.start_downloads_in_tmp_dir, but Policies.jsm uses browser.download*s*.start_downloads_in_tmp_dir. The release page also has the s.

Ugh. This is what I get for not also writing a test for the policy version of the thing, I guess?

Pascal, can you update the release notes?

I'll file a follow-up to fix the enterprise policy. The staticpreflist.yaml is correct; the prefix matches the other prefs.

Comment 137

[Pascal Chevrel:pascalc (PTO until April 26)]

Note updated, will be live in 30mn.

Comment 138

[Adrian Florinescu [:aflorinescu]]

Using STR to cover the details from comment 133 (thanks :Gijs for the explicit scenarios) with 102.0b3 on Windows 10, Mac 11 and Ubuntu 22.04 + Ubuntu 21.10.

The only issue I've hit is related to snap Ubuntu, which for temp case, it won't open neither the download or the download folder. For the download folder, I'll get:

Failed to query file manager: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.229" (uid=1001 pid=36282 comm="/snap/firefox/1422/usr/lib/firefox/firefox " label="snap.firefox.firefox (enforce)") interface="org.freedesktop.FileManager1" member="ShowItems" error name="(unset)" requested_reply="0" destination=":1.257" (uid=1001 pid=47964 comm="/usr/bin/nautilus --gapplication-service " label="unconfined")

Seems I'm hitting known issues of sorts: bug 1664824 or bug 1656713. I'll mark as verified and spin off a new issue once I'll get to investigate a bit more.

Comment 141

[Pascal Chevrel:pascalc (PTO until April 26)]

This was in our nightly and beta notes and should be documented for the release in the enterprise policy updates (https://support.mozilla.org/kb/firefox-enterprise-102-release-notes, not yet live).