Bugzilla

(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 are not actually "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 is changing 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. But I'm willing to spend my own time trying to find a solution that will please as many people as possible.

However, that 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.

(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 are not actually "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. But I'm willing to spend my own time trying to find a solution that will please as many people as possible.

However, that 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.

(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 are not actually "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. 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.

(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 are not actually "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.

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