Closed Bug 1046958 Opened 6 years ago Closed 4 years ago
Firefox still hangs up and becomes nonresponsive on "save as
..." file download selection -- why?
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140716183446 Steps to reproduce: 1. File Download - Either a) right-click on file link and select "save as..." OR b) have FF download options set to "ask me" rather than specifying a fixed location. 2. Attach file to e-mail - I use the Compuserve/AOL Webmail interface (http://webmail.cs.com/) for e-mail service. Once logged in, if I initiate composition of an outgoing e-mail and click on the paper-clip icon to attach a specific file to the e-mail for sending, the same "hang" in FF occurs. Actual results: In both cases, FF seizes up ("busy" cursor displayed interminably without change) and requires 3-finger salute (<CTL> <ALT> <DEL>) to bring up Task Manager and manually kill the Firefox process (or process tree), then I have to re-launch FF. Expected results: In both cases, FF should bring up a file directory window to allow specification of the location where a) the linked download file is to be saved or b) the file to be attached to an outgoing e-mail is located. Please note - this topic has been the subject of the following online support threads: https://support.mozilla.org/en-US/questions/977944 https://support.mozilla.org/en-US/questions/1010130 jscher2000 suggested most recently in the latter thread that I submit a bug report for this issue. It ONLY occurs on one of my desktop machines running Win7 Ultimate x64, not on others running WinVista Ultimate x86 or WinXP Pro, and the problem does NOT occur with IE in attempting either action on the affected machine. The affected machine has been regularly scoured for malware by weekly scans of MSE, MalwareBytes, Kaspersky TDSS Killer, SuperAntiSpyware, and Panda Cloud AV, plus SFC and CHKDSK have been run repeatedly both independently as well as integrated within the Tweaking.com repair tool that has been run multiple times since the symptoms first appeared months and months ago on a much earlier version of FF. I've created new profiles, reset FF to its defaults, and tolerated the impediments the problem imposes but am really reaching the end of that tolerance.
Severity: normal → critical
QA Whiteboard: [bugday-20140804][DUPEME?]
Component: Untriaged → File Handling
I've focused on the possibility this issue is associated with the Windows Script engine, as that hypothesis was suggested in one of the earlier threads referenced above. A replacement of the engine's various extensions was released as a Windows security update (MS13-099, KB2892074) in December 2013, so I downloaded the 64-bit MSU installer file before uninstalling what had been implanted during a Windows Update session following that December release, changed the FF download option to "ask me where" from its fixed subdirectory setting (which doesn't trigger the hang) and rebooted the computer. I then tested the effects of removing that update on both of the two Firefox issues I've been experiencing (attaching a file to an e-mail in the AOL mail client and the capability to select any location for downloads) which trigger the hang. What I discovered may or may not prove helpful to the FF developers monitoring this thread -- the hanging issue did NOT occur in the e-mail file attachment process (separate window popped up displaying the list of files in a particular subdirectory that seems to have been the subdirectory where I last uploaded an attachment) the first time I tried it. I cancelled that action in order to test the download function, but when I did FF hung up as it has been -- forcing a 3-finger salute to kill the process tree. I relaunched FF but did NOT reboot the computer, and tested the e-mail file attachment function again -- it caused a hang this 2nd time, forcing another manual termination of the process. So, for the time being in order to be a bit more secure, I reinstalled the Windows KB2892074 x64 patch. I could be completely off-base, but whatever is triggering this hanging issue does seem to be related to the way in which scripting is handled between FF, Windows and the AOL webmail interface.
I am continually impacted by this in both FF and Thunderbird. For me, the hang only happens the first time I try to Save As or Attach. If I close the dialog (red cross; no need to kill process via TaskManager) and restart whichever app I was using, the Save As, Attach will work fine and then not reoccur until next reboot of machine.
(In reply to Mark Hagan from comment #2) > I am continually impacted by this in both FF and Thunderbird. > > For me, the hang only happens the first time I try to Save As or Attach. If > I close the dialog (red cross; no need to kill process via TaskManager) and > restart whichever app I was using, the Save As, Attach will work fine and > then not reoccur until next reboot of machine. That hasn't been my experience -- the symptom of hanging generally occurs every time and I have little choice but to exercise the process-killing option via TaskManager. For example, when a download box pops up and the hang begins, if I click on the red "X" to close that window another box from the OS pops up with the message that Firefox isn't responding and offers two options: shut it down or wait to see if it will respond (which it never does). Since employing that box's shutdown option typically won't recover the open tabs but start with the default webpage(s) I've established in the FF settings, I prefer the TM kill-process-tree option that will recover the open tabs upon restart.
Thanks for the tip Jim. Yes that's a better way to recover. I'll use that approach until we get a fix!
I'm uncertain whether this changed with the upgrade to v32.0.x or v33.0.x during the past few weeks, but at least some of the problematic behavior of Firefox I reported in this bug seems to have now been resolved -- I am consistently able to attach a file to an outgoing e-mail without having FF experience a seizure that requires termination of the application. I have not yet tested whether a problem still exists if the download settings option is set to "let me choose" rather than specifying a fixed download folder, but will undertake that test in the next day or so and report back with the outcome.
Alas, no joy. While very happy that I'm now able to consistently select and upload an e-mail file attachment, the "let me choose" download option toggled in FF settings still produces the hang-and-seizure behavior, forcing me to perform the 'three-fingered salute', bring up Task Manager and kill its process tree. Both times I've made the attempt still display two Flash processes (one with a high memory load, the other with a much lower memory load) along with the high-load FF process. Killing the Flash processes first doesn't affect the FF process, but killing the FF process first automatically terminates both Flash processes without my intervention.
The joy level has dropped further to a new low. Whatever may have occurred since the upgrade of FF to v33.1.1 along with the most recent Patch Tuesday MS updates (and one subsequent out-of-band update yesterday) has broken the consistency i reported above in being able to select e-mail file attachments, a process which had returned to "normal" but is now dysfunctional once again and produces the hanging behavior that requires manual termination of the FF process/process tree and a restart.
This behavior is still manifesting with the newer upgrades to Firefox 34.0.x, but DOES NOT OCCUR WHEN USING INTERNET EXPLORER, which allows me to select the download file location or e-mail attachments without producing any "hang" in the application. So, I am left with a conclusion that it is simply not an OS problem, and seems most likely to be a FF Windows script handling (or mishandling) issue.
STILL happening, and the companion foible triggered when attaching some file to an outgoing e-mail in AOL Webmail comes and goes, seemingly after a random change-of-version upgrade. Irritating to the point of nearing terminal frustration with FF...
UPDATE: I have replaced FF x86 with the latest (initially v45.0.3 then v46.0) native x64 version, uninstalling from the Control Panel, rebooting and installing the new version -- I waited to undertake this step until there was a CLEAR set of instructions from Mozilla Support that clarified the method for doing so which would retain all of the user profile and customization information, which thankfully went smoothly and produced that hoped-for outcome. After using the new x64 version for a few days, I thought I'd try to change the download option from a fixed location (D:) to "user select" and see whether the old freeze-up behavior still remained or had been successfully resolved. I'm VERY pleased to report that the user-selection download popups appear and function properly, and have tested the process over 5-10 successful attempts -- consequently, I'm going to request that the bug report be closed with a "solved" result. If it returns at any point, I'll submit a new bug report at that time.
Closing this bug according to reporter's latest comment
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
(In reply to Mark Hagan from comment #4) > Thanks for the tip Jim. Yes that's a better way to recover. I'll use that > approach until we get a fix! Mark, if you still see this problem, please file a new bug report
You need to log in before you can comment on or make changes to this bug.