Release Note Request (optional, but appreciated) [Why is this notable]: Number of requests after Fx99 [Affects Firefox for Android]: No [Suggested wording]: There is now an enterprise policy (`StartDownloadsInTempDirectory`) and an about:config pref (`browser.downloads.start_downloads_in_tmp_dir`) that will once again cause Firefox to put downloads in (a subfolder of) the OS temp folder, instead of the OS default downloads folder. Files opened from the "what should Firefox do with this file" dialog, or set to open in helper applications automatically, will stay in this folder. [Links (documentation, blog post, etc)]: none so far. Some other notes for folks CC'd here: - to be clear, assuming it doesn't get backed out this will be in tomorrow's Firefox 102 nightly build, and it will hit beta next week, and "regular" Firefox release in about a month. - it isn't possible to uplift this to 101 because (a) it contains localization changes, (b) 101 release candidates have already been built (release day is a week away) and (c) there is some risk here and it should have some baking time on nightly+beta. - as extensively discussed here and elsewhere, including bug 69938, there are downsides to flipping this pref; use at your own risk, yada yada yada - if you report bugs with this old-and-now-new behaviour, please be clear about the specific issue you're seeing, what prefs you have flipped (including this one), OS, whether you're using a snap build (NB: I expect it to go back to the weird special-snap-folder but ymmv; I wasn't in a position to test this), the contents of `handlers.json`, and an example (publicly accessible) download link that reproduces the issue (if the download link isn't public, please provide the server headers from the file, obtained via the browser console, [browser devtools](https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox) network monitor, or other network inspection) - downloads will also go back to being deleted after being opened (when Firefox shuts down), on non-macOS. This is separately configurable via `browser.helperApps.deleteTempFileOnExit` (a pre-existing pref). That pref doesn't affect downloads unless you also flip the `start_downloads_in_tmp_dir` one - automatically-opened (or opened-from-the-"what should Firefox do with this file"-dialog) private browsing downloads continue to be deleted when the private browsing session finishes irrespective of either pref. - the `browser.download.improvements_to_download_panel` will stop influencing the download destination behaviour, but... - if you've previously flipped the `browser.download.improvements_to_download_panel` pref to false, Firefox will automatically set the new pref for you.
Bug 1738574 Comment 133 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Release Note Request (optional, but appreciated) [Why is this notable]: Number of requests after Fx99 [Affects Firefox for Android]: No [Suggested wording]: There is now an enterprise policy (`StartDownloadsInTempDirectory`) and an about:config pref (`browser.downloads.start_downloads_in_tmp_dir`) that will once again cause Firefox to initially put downloads in (a subfolder of) the OS temp folder, instead of the download folder configured in Firefox. Files opened from the "what should Firefox do with this file" dialog, or set to open in helper applications automatically, will stay in this folder. Files saved (not opened as previously mentioned) will still end up in the Firefox download folder. [Links (documentation, blog post, etc)]: none so far. Some other notes for folks CC'd here: - to be clear, assuming it doesn't get backed out this will be in tomorrow's Firefox 102 nightly build, and it will hit beta next week, and "regular" Firefox release in about a month. - it isn't possible to uplift this to 101 because (a) it contains localization changes, (b) 101 release candidates have already been built (release day is a week away) and (c) there is some risk here and it should have some baking time on nightly+beta. - as extensively discussed here and elsewhere, including bug 69938, there are downsides to flipping this pref; use at your own risk, yada yada yada - if you report bugs with this old-and-now-new behaviour, please be clear about the specific issue you're seeing, what prefs you have flipped (including this one), OS, whether you're using a snap build (NB: I expect it to go back to the weird special-snap-folder but ymmv; I wasn't in a position to test this), the contents of `handlers.json`, and an example (publicly accessible) download link that reproduces the issue (if the download link isn't public, please provide the server headers from the file, obtained via the browser console, [browser devtools](https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox) network monitor, or other network inspection) - downloads will also go back to being deleted after being opened (when Firefox shuts down), on non-macOS. This is separately configurable via `browser.helperApps.deleteTempFileOnExit` (a pre-existing pref). That pref doesn't affect downloads unless you also flip the `start_downloads_in_tmp_dir` one - automatically-opened (or opened-from-the-"what should Firefox do with this file"-dialog) private browsing downloads continue to be deleted when the private browsing session finishes irrespective of either pref. - the `browser.download.improvements_to_download_panel` will stop influencing the download destination behaviour, but... - if you've previously flipped the `browser.download.improvements_to_download_panel` pref to false, Firefox will automatically set the new pref for you.
Release Note Request (optional, but appreciated) [Why is this notable]: Number of requests after Fx99 [Affects Firefox for Android]: No [Suggested wording]: There is now an enterprise policy (`StartDownloadsInTempDirectory`) and an about:config pref (`browser.downloads.start_downloads_in_tmp_dir`) that will once again cause Firefox to initially put downloads in (a subfolder of) the OS temp folder, instead of the download folder configured in Firefox. Files opened from the "what should Firefox do with this file" dialog, or set to open in helper applications automatically, will stay in this folder. Files saved (not opened as previously mentioned) will still end up in the Firefox download folder. [Links (documentation, blog post, etc)]: none so far. Some other notes for folks CC'd here: - to be clear, assuming it doesn't get backed out this will be in tomorrow's Firefox 102 nightly build, and it will hit beta next week, and "regular" Firefox release in about a month. - it isn't possible to uplift this to 101 because (a) it contains localization changes, (b) 101 release candidates have already been built (release day is a week away) and (c) there is some risk here and it should have some baking time on nightly+beta. - as extensively discussed here and elsewhere, including bug 69938, there are downsides to flipping this pref; use at your own risk, yada yada yada - if you report bugs with this old-and-now-new behaviour, please be clear about the specific issue you're seeing, what prefs you have flipped (including this one), OS, whether you're using a snap build (NB: I expect it to go back to the weird special-snap-folder but ymmv; I wasn't in a position to test this), the contents of `handlers.json`, and an example (publicly accessible) download link that reproduces the issue (if the download link isn't public, please provide the server headers from the file, obtained via the browser console, [browser devtools](https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox) network monitor, or other network inspection) - downloads will also go back to being deleted after being opened (when Firefox shuts down) with this pref flipped, on non-macOS. This is separately configurable via `browser.helperApps.deleteTempFileOnExit` (a pre-existing pref). That pref doesn't affect downloads unless you also flip the `start_downloads_in_tmp_dir` one - automatically-opened (or opened-from-the-"what should Firefox do with this file"-dialog) private browsing downloads continue to be deleted when the private browsing session finishes irrespective of either pref. - the `browser.download.improvements_to_download_panel` will stop influencing the download destination behaviour, but... - if you've previously flipped the `browser.download.improvements_to_download_panel` pref to false, Firefox will automatically set the new pref for you.
Release Note Request (optional, but appreciated) [Why is this notable]: Number of requests after Fx99 [Affects Firefox for Android]: No [Suggested wording]: There is now an enterprise policy (`StartDownloadsInTempDirectory`) and an about:config pref (`browser.downloads.start_downloads_in_tmp_dir`) that will once again cause Firefox to initially put downloads in (a subfolder of) the OS temp folder, instead of the download folder configured in Firefox. Files opened from the "what should Firefox do with this file" dialog, or set to open in helper applications automatically, will stay in this folder. Files saved (not opened as previously mentioned) will still end up in the Firefox download folder. [Links (documentation, blog post, etc)]: none so far. Some other notes for folks CC'd here: - to be clear, assuming it doesn't get backed out this will be in tomorrow's Firefox 102 nightly build, and it will hit beta next week, and "regular" Firefox release in about a month. - it isn't possible to uplift this to 101 because (a) it contains localization changes, (b) 101 release candidates have already been built (release day is a week away) and (c) there is some risk here and it should have some baking time on nightly+beta. - as extensively discussed here and elsewhere, including bug 69938, there are downsides to flipping this pref; use at your own risk, yada yada yada - if you report bugs with this old-and-now-new behaviour, please be clear about the specific issue you're seeing, what prefs you have flipped (including this one), OS, whether you're using a snap build (NB: I expect it to go back to the weird special-snap-folder but ymmv; I wasn't in a position to test this), the contents of `handlers.json`, and an example (publicly accessible) download link that reproduces the issue (if the download link isn't public, please provide the server headers from the file, obtained via the browser console, [browser devtools](https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox) network monitor, or other network inspection) - downloads will also go back to being deleted after being opened (when Firefox shuts down) with this pref flipped, on non-macOS. This is separately configurable via `browser.helperApps.deleteTempFileOnExit` (a pre-existing pref). That pref doesn't affect downloads unless you also flip the `start_downloads_in_tmp_dir` one - automatically-opened (or opened-from-the-"what should Firefox do with this file"-dialog) private browsing downloads continue to be deleted when the private browsing session finishes irrespective of either pref. - the `browser.download.improvements_to_download_panel` will stop influencing the download destination behaviour, but... - if you've previously flipped the `browser.download.improvements_to_download_panel` pref to false, Firefox will automatically set the new pref for you (ie you shouldn't see a change to the destination used)