Setting for Download Folder Not Saved
Hello, I have a user that likes to change the setting for the downloads location to "Always ask you where to save files". When this setting is changed, I can see that it's saved in the prefs.js file, and also in about:config.
But when the user is restarting Firefox, the setting is reset to the default Downloads folder. This happens to all computers and different users. We're using Firefox 57.0
What can I do to save this setting?
sowitec moo ko soppali ci
All Replies (6)
Hi, I always have downloads set to "Always ask you where to save files" myself and it is working fine with three machines running Windows (one on 7 home and two on 10 pro). I attach a snapshot of the save file browser screen (with some person bits blanked out).
There are a number of lines in the prefs.js file concerning download and this is what mine shows at the moment (search results from Notepad++ for all occurrences with Line numbers):
Line 30: user_pref("browser.download.autohideButton", false); Line 31: user_pref("browser.download.lastDir", "D:\\hubiC\\@DEV\\"); Line 32: user_pref("browser.download.panel.shown", true); Line 33: user_pref("browser.download.save_converter_index", 0); Line 34: user_pref("browser.download.useDownloadDir", false); Line 34: user_pref("browser.download.useDownloadDir", false); Line 74: user_pref("browser.uiCustomization.state", "{\"placements\":{\"widget-overflow-fixed-list\":[],\"PersonalToolbar\":[\"personal-bookmarks\"],\"nav-bar\":[\"back-button\",\"forward-button\",\"save-page-button\",\"bookmarks-menu-button\",\"sidebar-button\",\"home-button\",\"urlbar-container\",\"stop-reload-button\",\"_cd7e22de-2e34-40f0-aeff-cec824cbccac_-browser-action\",\"find-button\",\"library-button\",\"downloads-button\",\"firefox_smarttube_io-browser-action\",\"_b3e677f4-1150-4387-8629-da738260a48e_-browser-action\",\"_3b56bcc7-54e5-44a2-9b44-66c3ef58c13e_-browser-action\",\"developer-button\",\"_677a8f98-fd64-40b0-a883-b8c95d0cbf17_-browser-action\",\"87677a2c52b84ad3a151a4a72f5bd3c4_jetpack-browser-action\",\"_testpilot-containers-browser-action\",\"customizableui-special-spring8\",\"customizableui-special-spring9\",\"chrome-store-foxified_jetpack-browser-action\"],\"TabsToolbar\":[\"tabbrowser-tabs\",\"new-tab-button\",\"alltabs-button\"],\"toolbar-menubar\":[\"menubar-items\"]},\"seen\... Line 142: user_pref("pref.downloads.disable_button.edit_actions", false);
I am not an expert on this, just a volunteer helper, but if your user's settings are something similar but it is not working, I wonder if an installed Addon is somehow overriding the normally set download preference?
Could you check all addons/extensions installed?
If it is not that, I personally have no idea why it is not working, but perhaps someone else might know more things to check and post here?
Thanks for your reply. The setting is this one: Line 34: user_pref("browser.download.useDownloadDir", false); When I change the setting, it's set to "false".
But after a Firefox restart, it's set to "true" - same like in about:config.
Regarding add-ons: I don't have any installed.
You can check if you have a user.js file in the profile folder to initialize prefs each time Firefox starts. The user.js file will only be present if you or other software has created this file and normally won't be present.
You can check its content with a text editor (right-click: "Open with"; do not double-click). The user.js file is read each time Firefox is started and initializes preferences to the value specified in this file, so preferences set via user.js can only be changed temporarily for the current session.
You can delete the user.js file if you didn't create this file yourself.
You can use the button on the "Help -> Troubleshooting Information" (about:support) page to go to the current Firefox profile folder or use the about:profiles page.
- Help -> Troubleshooting Information -> Profile Directory:
Windows: Show Folder; Linux: Open Directory; Mac: Show in Finder - http://kb.mozillazine.org/Profile_folder_-_Firefox
Thank you cor-el :)
It does sound like this user has a user.js file (which I do not have).
I did some repetitive testing of different settings of my own system, trying 3 different settings:
- "Save files to" Downloads
- "Save files to" D:\DTEMP
- "Always ask you where to save files"
Looking carefully at the prefs.js file each time (and testing the setting).
The ONLY time that I see the "browser.download.useDownloadDir" listed is for the third option, "Always ask you where to save files" where it is set to false, i.e.
user_pref("browser.download.useDownloadDir", false);
I NEVER see it as
user_pref("browser.download.useDownloadDir", true);
Thanks for your information. @RichardInEngland: I see the setting as user_pref("browser.download.useDownloadDir", true); and when I change to "Always ask you where to save files", it's set to false (like you said), but when I restart Firefox, it changes to true again.
@cor-el: I checked the profile directory, and there's no user.js file :-(
Additional information: First I was thinking that Firefox for some reason doesn't at all save settings, but this turned out to be not true. It DOES save settings, this download directory setting is the only one that gets reset every time.
Just to be clear in my previous answer, immediately on using the "Save files to" <somewhere> setting, the "browser.download.useDownloadDir" flag does not appear at all in the prefs.js file (either when I refresh Notepad++ immediately after changing the setting, or after shutting down and restarting Firefox).
It seems that in your case, "something" is changing your prefs.js file when you restart Firefox (or possibly during its last shutdown?). If it is not a user.js file, I at a loss to know what it is.
I wonder if there is a user.js file in a different location, other than your Firefox profile directory, that is still managing to run?
I expect that cor-el will be able to help you better :)
<Edit> I just had a sudden thought, if having a user.js file in the profile directory is not causing the problem, perhaps creating one to put in the right setting might be a workaround (assuming that at run-time it can undo whatever is causing the current problem anyway!)? But I would see what cor-el or someone else more knowledgeable than myself on this has to say.
RichardInEngland moo ko soppali ci