Bugzilla

(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 Microsoft Edge'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](https://searchfox.org/mozilla-central/rev/09872c789843daf3dc05817c4197c4a82d39bf24/toolkit/components/downloads/DownloadCore.jsm#621-623). 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.

(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](https://searchfox.org/mozilla-central/rev/09872c789843daf3dc05817c4197c4a82d39bf24/toolkit/components/downloads/DownloadCore.jsm#621-623). 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.