Cuireadh an snáithe seo sa chartlann. Cuir ceist nua má tá cabhair uait.
Problem with download setting "Always ask me where to save files" in v25.0+?
Since upgrading to v25.0 and then v25.0.1, there seems to be a consistent problem on one of my desktops running Win7 Ultimate x64 with having the download setting in Options toggled to the "ask user" setting -- seems to work fine when a particular subdirectory is specified, but the program hangs (with the OS "waiting" icon displayed) for an indefinite period of time until I use Task Manager to terminate the process or process tree. This sort of behavior did not occur with older FF versions <25.
Before I discovered the problem didn't occur when a subdirectory was specified, I had followed the advice reflected in an online troubleshooting article to sequentially 1) clear the download history and then 2) change the post-download AV check from "true" to "false" in the configuration settings, but neither of those steps enabled success with the user-request toggled and the program would repeatedly hang. Finally I tried the other setting by specification of the root drive "Temp" folder, and discovered that it would work successfully. Changing it back to the user-request setting again causes the program to hang when another attempt to download the same file from either an e-mail attachment or different website is attempted.
Is this a bug of some sort, or is there some other FF setting which might be triggering the dysfunctional effect for this machine (doesn't seem to occur with other machines running FF v25.0.1 with 32-bit OS flavors of XP Pro or Vista Ultimate)? If the former, please let me know if you need further information to correct it for future releases. If not and no other FF setting would likely trigger such an effect, that would imply some sort of external cause but the behavior doesn't occur with IE (I don't/won't use Chrome). FWIW, I use MSE as my primary resident AV in conjunction with Panda Cloud AV running in parallel (and I have had zero issues or problems with any conflict arise in this arrangement for the past 3+ years on any of the machines in my home office).
All Replies (18)
The only thing that comes to mind is: have you ever used the dialog to save onto removable media that is not currently present on the system?
Also, have you shut down and restarted Windows since this started happening in case some shared component has crashed?
A couple other preferences you might clear or create. Don't know whether these changes will have any effect.
(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.
(2) In the search box above the list, type or paste download and pause while the list is filtered
(3) Right-click the browser.download.lastDir preference and choose Reset to clear it.
(4) Turn off use of site-specific download directories (i.e., defaulting to the last location for a particular site). This requires creating a new preference that doesn't normally exist. See: https://support.mozilla.org/en-US/que.../972823#answer-484749 for details.
Regrettably, neither of the actions in #3 or #4 seem to have ameliorated the problem -- any other thoughts or advice?
I should have included in the original message that the lockup symptom also occurs with a simple right-click to bring up a separate context window and selecting "Save as" for an active link to any file. Does that indicate the root of this particular issue might be due to something in the OS rather than FF itself? Since the problem didn't start to arise until after a FF upgrade to v25+ and this is the only 64-bit OS I have working at the moment to test against, that angle just occurred to me.
As a test to see whether your Firefox program files might have gotten corrupted, could you do a two-minute experiment?
Create a new Firefox profile
The new profile (new Firefox personal settings folder) will have your system-installed plugins (e.g., Flash) and extensions (e.g., security suite toolbars), but no themes, other extensions, or other customizations. It also should have completely fresh settings databases and a fresh cache folder.
Exit Firefox and start up in the Profile Manager using Start > search box (or Run):
Any time you want to switch profiles, exit Firefox and return to this dialog.
When creating a new profile, I recommend using the default location suggested, and to avoid data loss, not re-using any existing folder. Before deleting unneeded profiles, I suggest making a backup first in case something were to go wrong.
Can you save a file in the new profile (in a folder of your choosing, of course)?
This could be a problem with the default download location (usually My Documents\Downloads).
What is the current default Download location?
- Tools > Options > General : Downloads
You can open the about:config page via the location bar and search for 'download' prefs.
User set (bold) prefs can possibly be reset via the right-click context menu to the default value.
I've used both C:\Temp and D:\ as the default setting before (currently is D:\), but really prefer the option which used to work that allows user-selection for each download. Guess I'll have to create another new profile (this will be the 2nd time after a previous, different glitch required that step to overcome) and see if that will resolve this issue, but it is such a PITA to go through all of the re-customization process I'll need to wait a bit longer until I have more time to devote on it.
This is SUCH an incredible PITA -- once again, I created a new profile and brought in the various personalized add-ons, themes and extensions, and have gone through a rather exhaustive/interminable process of teaching NoScript which scripts to allow and which to block -- disabling Ghostery completely after it began consistently failing to present its icon so the blocking action(s) could be tailored on-the-fly as necessary, and having their tech people respond to my inquiries with little more than "we're working on it". Yet FF still locks up when the download option "always ask me where to save files" is toggled, although when a specific subdirectory location (like C:\Temp or D:\) is toggled it will not lock up.
So what gives with this bug, and more importantly, when will it be fixed? It IS a bug from what I can ascertain, but I have not reported it as such before this point -- perhaps I should.
I suggest filing a new bug. The developers can let you know if they need debug information or other data that forum volunteers don't normally ask about.
Also, in case you need it in the future, NoScript has import and export features for your whitelist. Although... will you be able to save it? Hmm... might be safer to open your old prefs.js file and copy that one preference to the new file.
You can try to delete both prefs.js and the content-prefs.sqlite file in the Profile Folder.
The latter stores the download location that are used for websites.
Current Firefox versions remember the download directory based upon the URL, so if the URL changes then the default folder may be chosen if there hasn't been selected a download folder before for that server.
You can disable this feature to remember the download directory via the Boolean pref browser.download.lastDir.savePerSite on the about:config page. The browser.download.lastDir.savePerSite pref doesn't exist by default (it is a hidden pref), so you need to create it.
Create a new Boolean pref with the name browser.download.lastDir.savePerSite and set the value to false.
Success! I never had to add the new feature, as apparently deleting both of those particular files universally has accomplished the trick -- I performed a computer-wide search for each filename with Windows Explorer, and deleted every instance which it found in the various profile subdirectories which exists (there are now three, with the one most recent being the default). Interestingly -- and this may have been a key factor -- there were TWO prefs.js files (exact same filename) residing in one of the older profile subdirectories, despite having no (2) or (copy) aspect in its name as shown in the Windows Explorer listing. I didn't think it was possible to have exact filename duplicates in the same subdirectory/folder location unless they were distinguished by the OS somehow in using one or the other of those appellations, but whatever produced that duplicate may have been the principal reason for the glitchy behavior.
So, I deleted all such filenames for both prefs.js and content-prefs.sqlite following their respective searches (one entry of which required me to shut down Firefox from the background since it was in use), rebooted and launched FF then changed the download location to "ask me each time" in the options -- have just now tried it and not only does that box pop up properly but the downloading to that selected location is accomplished without any apparent issues.
If there is a problem resolution toggle for this issue, following the indicated link from your e-mailed notice of the post generated a 404 error so I couldn't indicate that way that the problem had been resolved. Hopefully, this behavior won't be recurrent at any point, but if it does I'll repeat the search-and-delete process to see if there is once again a duplicate file with the same name and whether deleting it/them will resolve the issue. I may post a further response to this thread if so with the circumstances and outcome, but otherwise I think you can consider this problem to have been resolved -- many thanks to both you and jscher2000 for your advice and suggestions in overcoming the issue.
You said in your last post that the problem is now resolved, so I'll mark the post by cor-el (where he suggested, to delete both prefs.js and the content-prefs.sqlite file in the Profile Folder) as the solution.
Thanks for posting back with details on how you solved the problem.
Well, I thought it had been resolved but apparently that's still not the case. After I had posted that message about apparent success, I discovered that while the download function would work find IF a particular location was specified, Firefox would still hang up in never-never land if the option to "ask me where" was toggled. So, I simply set it aside to focus on other things and finally got around a few days ago on this one x64 machine to do a complete removal using Revo Uninstaller Pro in 'aggressive' mode. Since it starts with the built-in FF uninstaller I selected the option NOT to retain anything from the existing installation when presented with that question, then selected and deleted EVERYTHING Revo found in terms of remaining Firefox-related files and file structure as well as all references it listed in the registry.
I rebooted, then re-installed FF v26 and have once again gone through the laborious process of personalizing it (have just upgraded to the newly-released v27), but that "ask me where to download" option still triggers a seizure that requires the three-fingered salute (i.e., Task Manager/Kill Process Tree) to resolve. So, I've changed the download option to a specific drive location, and will just have to endure a recurring bit of tedium to then transfer downloaded files to a more permanent location using Windows Explorer.
Is there possibly something in the Windows x64 architecture that's the culprit in this, since I don't have the issue in any of the x86 machines?
Boot the computer in Windows Safe Mode with network support (press F8 on the boot screen) as a test to see if that helps.
Do a malware check with some malware scanning programs on the Windows computer.
Please scan with all programs because each program detects different malware.
All these programs have free versions.
Make sure that you update each program to get the latest version of their databases before doing a scan.
- Malwarebytes' Anti-Malware:
- Microsoft Safety Scanner:
- Windows Defender: Home Page:
- Spybot Search & Destroy:
- Kasperky Free Security Scan:
You can also do a check for a rootkit infection with TDSSKiller.
- Anti-rootkit utility TDSSKiller:
- "Spyware on Windows": http://kb.mozillazine.org/Popups_not_blocked
Also, in case it helps, this is copied from http://kb.mozillazine.org/Firefox_hangs#Hang_downloading_files
Windows shell extension:
A Windows shell extension added by certain applications can cause Firefox to hang when trying to download and save a file or when opening "Options" or "Downloads" from the Firefox (Tools) menu. A program called WagerLogic and older versions of TortoiseCVS have been known to cause this problem. If you have one of these applications, try installing a newer version or else uninstall the application if you don't need it. Note: You can view and selectively disable Windows shell extensions added by third-party (non-Microsoft) applications with the ShellExView utility, to determine if one of them is causing the issue.
This is copied from https://bugzilla.mozilla.org/show_bug.cgi?id=587903#c6
Matthias Versen [:Matti] 2010-10-27 04:40:02 PDT Tortoise is causing the problem. This application installs a shell extension for File I/O and this shell extension hangs Firefox. Every time Firefox calls the windows function to open a windows filpicker this shell driver is loaded as well and hangs Firefox. It seems that they seem to fixed the bug in newer versions
You are not the original reporter of this bug but he never answered. I will mark this report as dupe of bug 573977
Athraithe ag AliceWyman ar
I already perform a weekly full malware scan on all my machines in the sequence below, and nothing's been identified on this or the others in my local network during any of the scans for months and months (and when something was, it was a false positive):
1. MSE 2. Kaspersky TDSS 3. Malwarebytes 4. SuperAntiSpyware 5. Panda Cloud AV
Since I've run the MS Safety Scanner and the online ESET scanner on this machine in the past few months as well as those weekly scans, I don't believe there is any malware lurking to cause this behavior. I also use CCleaner on a monthly basis after Patch Tuesdays to clean the bloatware that process leaves behind, and perform monthly defrags on the root drive.
I've used Spybot before in the past but stopped before v2 was released because it was conflicting with several apps, including the main resident AV I was using at the time (avast!) which I've since dropped it in favor of MSE -- not familiar with AdwCleaner but will give it a try over the weekend and post back.
I'll also explore further the shell extension angle raised by Alice, although I don't use either of the two apps she mentioned.
Something similar also happens with Firefox 24.3.0 ESR. I don't think it's version specific I think this is due to how and where Firefox stores it's preference files.
Problem: Downloading anything gets to the point where it asks you to save the file, and then returns back to the browser after you tell it to save and say where you want to save the file, but doesn't download the file or save the download link in the download history section.
Possible cause: the roaming appdata folder on our workstations is stored on the network, and when the network has issues then Firefox goes nuts with bookmarks disappearing and downloads/saving failing.
Usually restoring previous versions of the various .sqlite files does the trick. ie downloads and places, but it points to the fact that these files are easily corrupted, and it may be worth adding some safeguards into the transactions that take place on these files.
The other fix is to specify the download directory in the options menu.
Hope this helps - Matt.
Is Flash somehow involved in or called by Firefox either for the file-saving process mechanism or the mechanism by which an online e-mail client (in my case AOL) uses to attach a file from a user's hard drive to an e-mail message?
Not only do I still have the file-save location-specification problem which causes FF to seize and initiated this thread, but now I get a very similar behavior when attempting to attach a file to an outgoing e-mail before sending it. In both cases, when FF seizes up and I am subsequently required to perform the 3-finger salute (CTL-ALT-DEL) to bring up Task Manager and kill the FF process tree, there are not one but two Flash processes ongoing which are both absorbing a LOT of RAM memory along with FF's typically humongous amount (528 Mb when I discovered this latest wrinkle). Killing off first the larger of the two Flash processes doesn't appear to affect the state of FF's seizure or the other Flash process with a smaller memory footprint, nor does killing that 2nd Flash process resolve the issue so a direct kill of the FF process still must be taken with a restart to bring up the tabs which were previously open.
Just toggled the "add image-browse" button below this reply message box to see if that would also trigger a seizure, but it doesn't and properly brings up options with my HDD structure listed, so perhaps the AOL e-mail client function somehow uses embedded Flash or does something else comparable to whatever triggers the download "ask me" failure. I'm now working with v28.0, and the behavior is unique to this particular Win7 Ultimate x64 machine -- doesn't occur on a Vista Ultimate x86 or two XP Pro SP3 x86 machines in my home office, but I'm really trying to shut down use of those XP machines and this x64 box is to replace one of them.
I wasn't sure whether it would help resolve this problem, but one thing I attempted after posting the earlier message was to run (using IE, not FF) the online MS Windows Fixit tool for addressing problems with file folders and had the automatic fix option toggled. It found and presumably fixed one thing, but that did not resolve this FF file-save selection problem. When I tested the result, I did remember to take a screen shot of the Task Manager information before I killed the process trees of the 2 Flash processes and the FF process, and have attached it below. This time, the FF memory load was only ~370 Mb (still incredibly high IMHO).