搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

Learn More

Firefox still hangs up and becomes nonresponsive on "save as..." file download selection -- why?

  • 6 回覆
  • 6 有這個問題
  • 1 次檢視
  • 最近回覆由 jhvance

more options

I originally began this months ago in the now-archived topic at the URL below, but still have the problem.

https://support.mozilla.org/en-US/questions/977944?

I have been using a more indirect method as a workaround by specifying a download folder, then after it completes the download transferring the file(s) with Windows Explorer to the final preferred destination. Tedious, but tolerable.

However, something which is no longer tolerable is that I cannot attach any files to an outgoing e-mail message in my AOL/Compuserve Webmail account on this one Win7 Ultimate x64 machine -- toggling that 'paper clip' button generates the exact same behavior as the "save as..." freeze, forcing me to execute the 3-finger salute and kill the FF process tree (which is typically showing a large memory load and often a really high number of page faults). Generally, there are also two Flash processes which also have high memory loads that may be related, though I have no earthly idea why Flash would be invoked.

With the retirement of several XP machines in the past few months and the current hardware malfunction in my Win7 Pro x64 laptop's keyboard, I'm presently having to rely on this desktop to take care of business and the inability to attach files to outgoing e-mails is a serious impediment.

I've explored online whether the problem might lie with the shell extension for Windows script host (wshext.dll) as mentioned in that archived thread, but that DLL in this machine's system seems not to be corrupted and has the proper version and other attributes according to MS. I haven't been able to gain much traction along that pathway, although it seems reasonable that it might be involved with the problem. I've run the Tweaking.com all-in-one repair tool a number of times over the past several months as well as the MS chkdsk and sfc tools, but nothing has worked. Neither of these issues appear under IE so that tends to make me think it's something in FF and not the OS, but I absolutely hate using IE and would strongly prefer to overcome the problems in order to continue using FF.

And yes, all my OS, AV and various other executables are up-to-date and kept that way as quickly as I get notice from FileHippo or other sources that an update has been released.

So, I'm reposting this problem with a specific query about what actions or background processes are triggered by FF when the righ-click file download "save as..." option is toggled -- knowing that information might provide a little more guidance on where to look for prospective resolution.

I originally began this months ago in the now-archived topic at the URL below, but still have the problem. https://support.mozilla.org/en-US/questions/977944? I have been using a more indirect method as a workaround by specifying a download folder, then after it completes the download transferring the file(s) with Windows Explorer to the final preferred destination. Tedious, but tolerable. However, something which is no longer tolerable is that I cannot attach any files to an outgoing e-mail message in my AOL/Compuserve Webmail account on this one Win7 Ultimate x64 machine -- toggling that 'paper clip' button generates the exact same behavior as the "save as..." freeze, forcing me to execute the 3-finger salute and kill the FF process tree (which is typically showing a large memory load and often a really high number of page faults). Generally, there are also two Flash processes which also have high memory loads that may be related, though I have no earthly idea why Flash would be invoked. With the retirement of several XP machines in the past few months and the current hardware malfunction in my Win7 Pro x64 laptop's keyboard, I'm presently having to rely on this desktop to take care of business and the inability to attach files to outgoing e-mails is a serious impediment. I've explored online whether the problem might lie with the shell extension for Windows script host (wshext.dll) as mentioned in that archived thread, but that DLL in this machine's system seems not to be corrupted and has the proper version and other attributes according to MS. I haven't been able to gain much traction along that pathway, although it seems reasonable that it might be involved with the problem. I've run the Tweaking.com all-in-one repair tool a number of times over the past several months as well as the MS chkdsk and sfc tools, but nothing has worked. Neither of these issues appear under IE so that tends to make me think it's something in FF and not the OS, but I absolutely hate using IE and would strongly prefer to overcome the problems in order to continue using FF. And yes, all my OS, AV and various other executables are up-to-date and kept that way as quickly as I get notice from FileHippo or other sources that an update has been released. So, I'm reposting this problem with a specific query about what actions or background processes are triggered by FF when the righ-click file download "save as..." option is toggled -- knowing that information might provide a little more guidance on where to look for prospective resolution.

所有回覆 (6)

more options

FWIW, I should have also included this information in the original post -- right-clicking on a graphic image in any part of webpage to download it directly with the "save as" option produces the nonresponsive freeze as it would for any type of document-based (e.g. PDF) file, but the freeze will also occur if I right-click the image, select "view image" so it is a full-screen presentation, and then left-click "File|Save Page as" so there's no indirect workaround for downloading web-based images. By any approach, when the freeze occurs the cursor icon changes into its "busy" form (in accordance with the OS mouse cursor settings) and just stays that way until I take action to kill the FF process.

more options

Some websites use Flash for upload file selection between it can magically start uploading immediately, handles multiple uploads simultaneously, and provides a nice interface, which works around many of the limitations of regular HTTP file upload controls.

I'm not sure that Flash is relevant, but in case you have not already tried these standard troubleshooting tips for Flash:

(1) If you have any recorders/downloaders that interact with Flash media make sure they are as up-to-date as possible, or disable them temporarily.

(2) Disable Flash using hardware acceleration. See this support article from Adobe: http://helpx.adobe.com/flash-player/kb/video-playback-issues.html#main_Solve_video_playback_issues

(3) Disable the protected mode feature. This involves creating or editing a settings file. You can disable that by creating or editing a settings file. The following pages/posts provide different ways to do that:

Flash needs to completely unload from memory (exiting and starting Firefox up again might help) before this takes effect.

more options

For saving/downloading, Firefox should not use Flash. Instead, it should call a standard function of Windows that is made available to all programs. If you haven't already, you might want to run the System File Checker (sfc) to see whether any parts of Windows are damaged.

See: Use the System File Checker tool to repair missing or corrupted system files (MSKB 929833)

Edit: I see you already ran sfc

由 jscher2000 - Support Volunteer 於 修改

more options

Thanks for the input, but I've used SFC a number of times to try and correct whatever this problem involves, both independently of and incorporated within running the Tweaking.com repair tool -- no joy, unfortunately. CHKDSK as well, and I've created new profiles for FF too many times to count -- with zero change in the behavior.

I have been thinking it was possibly a Windows problem independent of Firefox, but have tested in IE all of the different actions which fail in Firefox and they work normally -- so, the fault somehow lies in/with Firefox or how it functions within Windows for those actions, not with the OS itself.

Does Mozilla have some sort of debug tool that I could run when the lockup is triggered and upload the output file which would subsequently enable the developers or tech staff to better identify what it is within FF that's producing this unpleasant behavior?

more options

I just re-read the earlier thread again, and I think it's time to file a bug on Bugzilla (assuming you didn't do that back then).

https://bugzilla.mozilla.org/

They sometimes will suggest debugging tools, and sometimes will suggest trying to find a regression range, in other words, testing around a certain point in time to determine which day's changes caused the problem.

more options

No, I haven't file a bugzilla report but will do so later today. Thanks.