Bugzilla

### Explanation
Previously, the "Open" action caused Firefox to save a download in a tmp directory and (in some environments) schedule it for deletion on app quit. That was removed with bug 1710926, creating a situation where downloads can quickly pile up in the user's chosen downloads directory.

To mitigate that issue, we previously added a new context menu item to allow users to delete download targets from the downloads panel and other views (bug 1745624). And I thought this was a pretty fine solution, and it's been working well for me ever since. But maybe because I was involved in the development, I'm hyper-conscious of the Delete menu item, so I have no trouble remembering to clean up the downloads panel.

Today I noticed [this thread](https://www.reddit.com/r/firefox/comments/tdohiy/firefox_98_download_manager_support_thread/) on r/firefox, in which it seems like the majority of users regard the temp folder problem as unresolved. Actually I didn't see a single person mention the Delete menu item as a solution. Instead, the "solution" that is being suggested to users is to toggle the experimental pref behind which all the downloads panel improvements are locked.

From that feedback it sounds like, even with the new menu item, we still haven't met the users' demands for some downloads directory housekeeping functionality. And, rather than deal with this trade-off, many users seem to prefer the temporary solution of disabling all the downloads panel improvements.

### Proposal
So, I would like to add a new preference that will automatically call `gExternalAppLauncher.deleteTemporaryFileOnExit` on download targets that are opened immediately — either as the handler's default action, or as a result of the unknown content type dialog, but not as a result of the regular "open" command called on an already "saved" download.

Let's say my handler action for application/pdf is "Open"; my handler action for application/octet-stream is "Save"; and my handler action for text/plain is "Always Ask".

I download a file of each type. (For now, don't worry about where they're saved) The PDF should be scheduled for deletion, but not the executable. The text file should only be scheduled for deletion if I chose "Open" in the UCT dialog.

Let's say I did it again but this time I chose "Save" in the dialog for the text file. Then, I open the downloads panel and I click the download element, or I right click it and click Open or Open in System Viewer or whatever. In these cases, it should not be scheduled for deletion, since I already chose to permanently save it.

So in simple terms, what I'm suggesting is that (locked behind a pref) if a download target is "opened" because its file handler's action is "Open" or because "Open" was chosen in the UCT dialog, it will be scheduled for deletion on app exit.

Also, I'd like to point out that I think the risk of unexpected data loss is pretty minimal. 2 reasons:
1. `gExternalAppLauncher.deleteTemporaryFileOnExit` doesn't do this already, but it's possible to make it set the permission bits in a recognizable way (as it does when making the file read-only), and then when the file is finally going to be deleted, check that the permission bits are still the same.
2. With bug 1746386 we should be adding file handle tracking, at least for this feature. So when that is done we don't need to delete the file by path alone. I would say, when the deletion method is finally called, it finds the file by handle _and_ checks that it still has the same path.

### Options
The next question is where such files should be saved.

#### Option #1
Technically it would be simplest to just save them exactly where they'd be saved otherwise, i.e., the user's default downloads dir. Because by the time an action has been taken in the UCT dialog, saver has already begun. But it would also be possible to move the download to a temp folder as part of this new method that schedules it for deletion.

The reason moving it to a temp folder might still be appealing, even though a similar feature was intentionally removed, is because users may not expect files in regular folders to be scheduled for deletion in the background. So, the unexpectedness of the behavior would preclude us from ever making this the default. By adding a pref we would be solving the problem for power users, but we couldn't enable it by default without probably causing confusion.

#### Option #2
Of course, if we added a checkbox for this _opt-in_ pref in about:preferences, the label could conceivably explain this, while making the option discoverable for most users. But I can't think of a concise wording that would really make it clear at the moment.

#### Option #3
But another option is to just move the download to a temp folder so that deletion is expected. From what I understand, one of the main issues with saving downloads to a temp folder is that their locations are not consistent on Linux distros? It seems like we could resolve that as follows:

- In about:preferences, underneath the downloads dir selector that says `Save files to [Downloads]`, we add a second path selector that says `Save temporary files to [/tmp]` so that user can manually choose their preferred temp folder path.
- Firefox tries to find a temp folder, maybe as an idle task at startup?
- If it doesn't find one, it toggles some property so that Firefox saves "opened" download targets in the regular downloads directory, and does _not_ schedule them for deletion (basically the current status quo)
- In this case where a temp folder was not found, Firefox should record the failure on some global component.
- When the user opens about:preferences, they should now see a little warning card above the `Save temporary files to [/tmp]` selector. And it says something like "Temporary directory not found. Choose a folder."
- The user chooses a temp folder, so now that toggled property is flipped back. The next time a download target is "opened", we save it there and schedule it for deletion.

Maybe there are some other considerations I haven't thought of. Let me know and I'll add them to this document. I don't think any of the above options is perfectly ideal, given the OS inconsistencies, but it seems like we have to do something about this. Since the temp folder changes have been shipped in a release build, we can see many more users grumbling about 1) unwanted temporary downloads (PDFs, archives, etc.) piling up in the downloads directory, and 2) part files getting stuck in a permanent download dir (cf. bug 1759670). So if there's a better solution that will have the same effect, please share 🙏

### Explanation
Previously, the "Open" action caused Firefox to save a download in a tmp directory and (in some environments) schedule it for deletion on app quit. That was removed with bug 1710926, creating a situation where downloads can quickly pile up in the user's chosen downloads directory.

To mitigate that issue, we previously added a new context menu item to allow users to delete download targets from the downloads panel and other views (bug 1745624). And I thought this was a pretty fine solution, and it's been working well for me ever since. But maybe because I was involved in the development, I'm hyper-conscious of the Delete menu item, so I have no trouble remembering to clean up the downloads panel.

Today I noticed [this thread](https://www.reddit.com/r/firefox/comments/tdohiy/firefox_98_download_manager_support_thread/) on r/firefox, in which it seems like the majority of users regard the temp folder problem as unresolved. Actually I didn't see a single person mention the Delete menu item as a solution. Instead, the "solution" that is being suggested to users is to toggle the experimental pref behind which all the downloads panel improvements are locked.

From that feedback it sounds like, even with the new menu item, we still haven't met the users' demands for some downloads directory housekeeping functionality. And, rather than deal with this trade-off, many users seem to prefer the temporary solution of disabling all the downloads panel improvements.

### Proposal
So, I would like to add a new preference that will automatically call `gExternalAppLauncher.deleteTemporaryFileOnExit` on download targets that are opened immediately — either as the handler's default action, or as a result of the unknown content type dialog, but not as a result of the regular "open" command called on an already "saved" download.

Let's say my handler action for application/pdf is "Open"; my handler action for application/octet-stream is "Save"; and my handler action for text/plain is "Always Ask".

I download a file of each type. (For now, don't worry about where they're saved) The PDF should be scheduled for deletion, but not the executable. The text file should only be scheduled for deletion if I chose "Open" in the UCT dialog.

Let's say I did it again but this time I chose "Save" in the dialog for the text file. Then, I open the downloads panel and I click the download element, or I right click it and click Open or Open in System Viewer or whatever. In these cases, it should not be scheduled for deletion, since I already chose to permanently save it.

So in simple terms, what I'm suggesting is that (locked behind a pref) if a download target is "opened" because its file handler's action is "Open" or because "Open" was chosen in the UCT dialog, it will be scheduled for deletion on app exit.

Also, I'd like to point out that I think the risk of unexpected data loss is pretty minimal. 2 reasons:
1. `gExternalAppLauncher.deleteTemporaryFileOnExit` doesn't do this already, but it's possible to make it set the permission bits in a recognizable way (as it does when making the file read-only), and then when the file is finally going to be deleted, check that the permission bits are still the same.
2. With bug 1746386 we should be adding file handle tracking, at least for this feature. So when that is done we don't need to delete the file by path alone. I would say, when the deletion method is finally called, it finds the file by handle _and_ checks that it still has the same path.

### Options
The next question is where such files should be saved.

#### Option #1
Technically it would be simplest to just save them exactly where they'd be saved otherwise, i.e., the user's default downloads dir. Because by the time an action has been taken in the UCT dialog, saver has already begun. But it would also be possible to move the download to a temp folder as part of this new method that schedules it for deletion.

The reason moving it to a temp folder might still be appealing, even though a similar feature was intentionally removed, is because users may not expect files in regular folders to be scheduled for deletion in the background. So, the unexpectedness of the behavior would preclude us from ever making this the default. By adding a pref we would be solving the problem for power users, but we couldn't enable it by default without probably causing confusion.

#### Option #2
Of course, if we added a checkbox for this _opt-in_ pref in about:preferences, the label could conceivably explain this, while making the option discoverable for most users. But I can't think of a concise wording that would really make it clear at the moment.

#### Option #3
But another option is to just move the download to a temp folder so that deletion is expected. From what I understand, one of the main issues with saving downloads to a temp folder is that their locations are not consistent on Linux distros? It seems like we could resolve that as follows:

- In about:preferences, underneath the downloads dir selector that says `Save files to [Downloads]`, we add a second path selector that says `Save temporary files to [/tmp]` so that user can manually choose their preferred temp folder path.
- Firefox tries to find a temp folder, maybe as an idle task at startup?
- If it doesn't find one, it toggles some property so that Firefox saves "opened" download targets in the regular downloads directory, and does _not_ schedule them for deletion (basically the current status quo)
- In this case where a temp folder was not found, Firefox should record the failure on some global component.
- When the user opens about:preferences, they should now see a little warning card above the `Save temporary files to [/tmp]` selector. And it says something like "Temporary directory not found. Choose a folder."
- The user chooses a temp folder, so now that toggled property is flipped back. The next time a download target is "opened", we save it there and schedule it for deletion.

Maybe there are some other considerations I haven't thought of. Let me know and I'll add them to this document. I don't think any of the above options is perfectly ideal, given the OS inconsistencies, but it seems like we have to do something about this.

I do know that Firefox was already unique in this feature. But Firefox users may have grown accustomed to their Downloads directory not ballooning with garbage (I certainly have). For some users, that may have been one of the main reasons they continued to use Firefox instead of Chrome, despite other trade-offs like worse integration with Google services, more Captchas, etc. So by following Chrome and taking it away, we're providing users with one fewer reason to choose Firefox over Chrome.

Since the temp folder changes have been shipped in a release build, we can see many more users grumbling about 1) unwanted temporary downloads (PDFs, archives, etc.) piling up in the downloads directory, and 2) part files getting stuck in a permanent download dir (cf. bug 1759670). So if there's a better solution that will have the same effect, please share 🙏

### Explanation
Previously, the "Open" action caused Firefox to save a download in a tmp directory and (in some environments) schedule it for deletion on app quit. That was removed with bug 1710926, creating a situation where downloads can quickly pile up in the user's chosen downloads directory.

To mitigate that issue, we previously added a new context menu item to allow users to delete download targets from the downloads panel and other views (bug 1745624). And I thought this was a pretty fine solution, and it's been working well for me ever since. But maybe because I was involved in the development, I'm hyper-conscious of the Delete menu item, so I have no trouble remembering to clean up the downloads panel.

Today I noticed [this thread](https://www.reddit.com/r/firefox/comments/tdohiy/firefox_98_download_manager_support_thread/) on r/firefox, in which it seems like the majority of users regard the temp folder problem as unresolved. Actually I didn't see a single person mention the Delete menu item as a solution. Instead, the "solution" that is being suggested to users is to toggle the experimental pref behind which all the downloads panel improvements are locked.

From that feedback it sounds like, even with the new menu item, we still haven't met the users' demands for some downloads directory housekeeping functionality. And, rather than deal with this trade-off, many users seem to prefer the temporary solution of disabling all the downloads panel improvements.

### Proposal
So, I would like to add a new preference that will automatically call `gExternalAppLauncher.deleteTemporaryFileOnExit` on download targets that are opened immediately — either as the handler's default action, or as a result of the unknown content type dialog, but not as a result of the regular "open" command called on an already "saved" download.

Let's say my handler action for application/pdf is "Open"; my handler action for application/octet-stream is "Save"; and my handler action for text/plain is "Always Ask".

I download a file of each type. (For now, don't worry about where they're saved) The PDF should be scheduled for deletion, but not the executable. The text file should only be scheduled for deletion if I chose "Open" in the UCT dialog.

Let's say I did it again but this time I chose "Save" in the dialog for the text file. Then, I open the downloads panel and I click the download element, or I right click it and click Open or Open in System Viewer or whatever. In these cases, it should not be scheduled for deletion, since I already chose to permanently save it.

So in simple terms, what I'm suggesting is that (locked behind a pref) if a download target is "opened" because its file handler's action is "Open" or because "Open" was chosen in the UCT dialog, it will be scheduled for deletion on app exit.

Also, I'd like to point out that I think the risk of unexpected data loss is pretty minimal. 2 reasons:
1. `gExternalAppLauncher.deleteTemporaryFileOnExit` doesn't do this already, but it's possible to make it set the permission bits in a recognizable way (as it does when making the file read-only), and then when the file is finally going to be deleted, check that the permission bits are still the same.
2. With bug 1746386 we should be adding file handle tracking, at least for this feature. So when that is done we don't need to delete the file by path alone. I would say, when the deletion method is finally called, it finds the file by handle _and_ checks that it still has the same path.

### Options
The next question is where such files should be saved.

#### Option #1
Technically it would be simplest to just save them exactly where they'd be saved otherwise, i.e., the user's default downloads dir. Because by the time an action has been taken in the UCT dialog, saver has already begun. But it would also be possible to move the download to a temp folder as part of this new method that schedules it for deletion.

The reason moving it to a temp folder might still be appealing, even though a similar feature was intentionally removed, is because users may not expect files in regular folders to be scheduled for deletion in the background. So, the unexpectedness of the behavior would preclude us from ever making this the default. By adding a pref we would be solving the problem for power users, but we couldn't enable it by default without probably causing confusion.

#### Option #2
Of course, if we added a checkbox for this _opt-in_ pref in about:preferences, the label could conceivably explain this, while making the option discoverable for most users. But I can't think of a concise wording that would really make it clear at the moment.

#### Option #3
But another option is to just move the download to a temp folder so that deletion is expected. From what I understand, one of the main issues with saving downloads to a temp folder is that their locations are not consistent on Linux distros? It seems like we could resolve that as follows:

- In about:preferences, underneath the downloads dir selector that says `Save files to [Downloads]`, we add a second path selector that says `Save temporary files to [/tmp]` so that user can manually choose their preferred temp folder path.
- Firefox tries to find a temp folder, maybe as an idle task at startup?
- If it doesn't find one, it toggles some property so that Firefox saves "opened" download targets in the regular downloads directory, and does _not_ schedule them for deletion (basically the current status quo)
- In this case where a temp folder was not found, Firefox should record the failure on some global component.
- When the user opens about:preferences, they should now see a little warning card above the `Save temporary files to [/tmp]` selector. And it says something like "Temporary directory not found. Choose a folder."
- The user chooses a temp folder, so now that toggled property is flipped back. The next time a download target is "opened", we save it there and schedule it for deletion.

Maybe there are some other considerations I haven't thought of. Let me know and I'll add them to this document. I don't think any of the above options is perfectly ideal, given the OS inconsistencies, but it seems like we have to do something about this.

I do know that Firefox was already unique in this feature. But Firefox users may have grown accustomed to their Downloads directory not ballooning with garbage (I certainly have). For some users, that may have been one of the main reasons they continued to use Firefox instead of Chrome, despite other trade-offs like worse integration with Google services, more Captchas, etc. So by following Chrome and taking it away, we're providing users with one fewer reason to choose Firefox over Chrome.

Since the temp folder changes have been shipped in a release build, we can see many more users grumbling about 1) unwanted download files that users perceive as temporary (PDFs, archives, etc.) piling up in the downloads directory, and 2) part files getting stuck in a permanent download dir (cf. bug 1759670). So if there's a better solution that will have the same effect, please share 🙏

### Explanation
Previously, the "Open" action caused Firefox to save a download in a tmp directory and (in some environments) schedule it for deletion on app quit. That was removed with bug 1710926, creating a situation where downloads can quickly pile up in the user's chosen downloads directory.

To mitigate that issue, we previously added a new context menu item to allow users to delete download targets from the downloads panel and other views (bug 1745624). And I thought this was a pretty fine solution, and it's been working well for me ever since. But maybe because I was involved in the development, I'm hyper-conscious of the Delete menu item, so I have no trouble remembering to clean up the downloads panel by manually using the context menu.

Today I noticed [this thread](https://www.reddit.com/r/firefox/comments/tdohiy/firefox_98_download_manager_support_thread/) on r/firefox, in which the majority of users seem to regard the temp folder problem as unresolved. Actually, I didn't see a single person reference the Delete menu item as a possible solution. Instead, the "solution" that is being suggested to users is to toggle the experimental pref behind which all the downloads panel improvements are locked.

From that feedback it sounds like, even with the new menu item, we still haven't met the users' demands for some downloads directory housekeeping functionality. And, rather than deal with this trade-off, many users seem to prefer the temporary solution of disabling all the downloads panel improvements.

### Proposal
So, I would like to add a new preference that will automatically call `gExternalAppLauncher.deleteTemporaryFileOnExit` on download targets that are opened immediately — either as the handler's default action, or as a result of the unknown content type dialog, but not as a result of the regular "open" command called on an already "saved" download.

Let's say my handler action for application/pdf is "Open"; my handler action for application/octet-stream is "Save"; and my handler action for text/plain is "Always Ask".

I download a file of each type. (For now, don't worry about where they're saved) The PDF should be scheduled for deletion, but not the executable. The text file should only be scheduled for deletion if I chose "Open" in the UCT dialog.

Let's say I did it again but this time I chose "Save" in the dialog for the text file. Then, I open the downloads panel and I click the download element, or I right click it and click Open or Open in System Viewer or whatever. In these cases, it should not be scheduled for deletion, since I already chose to permanently save it.

So in simple terms, what I'm suggesting is that (locked behind a pref) if a download target is "opened" because its file handler's action is "Open" or because "Open" was chosen in the UCT dialog, it will be scheduled for deletion on app exit.

Also, I'd like to point out that I think the risk of unexpected data loss is pretty minimal. 2 reasons:
1. `gExternalAppLauncher.deleteTemporaryFileOnExit` doesn't do this already, but it's possible to make it set the permission bits in a recognizable way (as it does when making the file read-only), and then when the file is finally going to be deleted, check that the permission bits are still the same.
2. With bug 1746386 we should be adding file handle tracking, at least for this feature. So when that is done we don't need to delete the file by path alone. I would say, when the deletion method is finally called, it finds the file by handle _and_ checks that it still has the same path.

### Options
The next question is where such files should be saved.

#### Option #1
Technically it would be simplest to just save them exactly where they'd be saved otherwise, i.e., the user's default downloads dir. Because by the time an action has been taken in the UCT dialog, saver has already begun. But it would also be possible to move the download to a temp folder as part of this new method that schedules it for deletion.

The reason moving it to a temp folder might still be appealing, even though a similar feature was intentionally removed, is because users may not expect files in regular folders to be scheduled for deletion in the background. So, the unexpectedness of the behavior would preclude us from ever making this the default. By adding a pref we would be solving the problem for power users, but we couldn't enable it by default without probably causing confusion.

#### Option #2
Of course, if we added a checkbox for this _opt-in_ pref in about:preferences, the label could conceivably explain this, while making the option discoverable for most users. But I can't think of a concise wording that would really make it clear at the moment.

#### Option #3
But another option is to just move the download to a temp folder so that deletion is expected. From what I understand, one of the main issues with saving downloads to a temp folder is that their locations are not consistent on Linux distros? It seems like we could resolve that as follows:

- In about:preferences, underneath the downloads dir selector that says `Save files to [Downloads]`, we add a second path selector that says `Save temporary files to [/tmp]` so that user can manually choose their preferred temp folder path.
- Firefox tries to find a temp folder, maybe as an idle task at startup?
- If it doesn't find one, it toggles some property so that Firefox saves "opened" download targets in the regular downloads directory, and does _not_ schedule them for deletion (basically the current status quo)
- In this case where a temp folder was not found, Firefox should record the failure on some global component.
- When the user opens about:preferences, they should now see a little warning card above the `Save temporary files to [/tmp]` selector. And it says something like "Temporary directory not found. Choose a folder."
- The user chooses a temp folder, so now that toggled property is flipped back. The next time a download target is "opened", we save it there and schedule it for deletion.

Maybe there are some other considerations I haven't thought of. Let me know and I'll add them to this document. I don't think any of the above options is perfectly ideal, given the OS inconsistencies, but it seems like we have to do something about this.

I do know that Firefox was already unique in this feature. But Firefox users may have grown accustomed to their Downloads directory not ballooning with garbage (I certainly have). For some users, that may have been one of the main reasons they continued to use Firefox instead of Chrome, despite other trade-offs like worse integration with Google services, more Captchas, etc. So by following Chrome and taking it away, we're providing users with one fewer reason to choose Firefox over Chrome.

Since the temp folder changes have been shipped in a release build, we can see many more users grumbling about 1) unwanted download files that users perceive as temporary (PDFs, archives, etc.) piling up in the downloads directory, and 2) part files getting stuck in a permanent download dir (cf. bug 1759670). So if there's a better solution that will have the same effect, please share 🙏