This is a meta bug for tracking defects related to the scheme we use in downloading files, whereby we first save them to a temp directory, then copy or move them to where the user specified. In the worst cases, we start saving the file to the temp directory before they dismiss the file save dialog, and we may even save the entire file without the user having clicked OK.

Saving the file after explicitly clicking a download link and before clicking "OK" in the Save dialogue is not necessarily a "defect". Actually, it is a *much requested and useful feature*, if done with a degree of care regarding the potential pitfalls (as *all* features have potential pitfalls). The above points have been well documented is several of the dependant bugs (especially bug 22796). I just wanted to make sure that the summary description of this bug ("In the worst cases...") doesn't stand uncorrected.

cc'ing Darin, MScott, Law to evaluate possibility of fixing these bugs by making design changes to temp file handling. Several of these bugs are still targeted for 1.0, but would such a change be too risky for MachV?

I think it is risky if we fundamentally change the way the uriloader/exthandler code currently does things. There are lots of things interconnected in subtle ways that are likely going to break if the current sequence of events is changed. A scheme by which things don't change except from a timing perspective would appear to be much less risky. In other words, if we left the uriloader/exthandler code alone (as much as possible) and tweaked the networking code so that OnDataAvailable notifications slowed to the extent that we could buffer in memory instead of a temporary file, then that might work.

> tweaked the networking code so that OnDataAvailable notifications slowed This would fail for at least one issue we have with the current setup -- the fact that we have to SetApplyConversion before we know whether we're saving to disk or opening with an app..... I _think_ the other issues we currently have should be resolved by this approach, though...

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!

not sure what list, so ->1.0.1

*** Bug 143843 has been marked as a duplicate of this bug. ***

*** Bug 145978 has been marked as a duplicate of this bug. ***

Well, the behaviour has it's pros and cons: Pro: Downloading is finished much faster, cause the download tool allready place in the background and the file is just copied to the place the user wanted. Good. Bad (Realy realy bad!): Large downloads fill up the tmp-filesystem and fail after 99.9 % leaving you behind with a full filesystem and a damaged file. After all you have to use a differnt download manager (i prefer wget or lynx in this cases) to get the file you need (Patches, Linux-ISO-Images and small stuff like that ;-). Ergo, it would be nice, to be able switch between the two downloads modes '1. Start download in the background' and '2. Download to User-specified place only' in the preferences. Don't know the code, but this should be possible.

Yes, having the file download in the background is good, except if the its large. I current download files with mozilla, and on my laptop it takes 5 minutes to move the file, causing mozilla to freeze, and use quite a few system resources. When you try to download 3 ISO's (for a new release) you need 2x the space, which really locks your browser, and cause the machine to use mass amount of cpu time. While the first method is best, low-mid end hardware can not keep up with large files. Lucky My 2ghz machine only takes 20-30 seconds, but its still annoying while your reading/typing an article, and the browser freezes.

Let's set one thing straight. The hang could be eliminated while keeping the "pre-download" behavior. We'd just need to not do it on the UI thread. So this is not really an issue... (see bug 55690 for what I consider issues).

We *could* do it, but it currently *is* an issue. Regardless of thread used for the copy, there would need to be UI showing the progress.

RE comment #12: > there would need to be UI showing the progress. +- Download Preferences ---------------------------------+ | | | Select location of partially downloaded files: | | ( ) OS's "Temp" directory | | ( ) Custom Directory [ D:\spool\ ] (browse) | | (*) Same as final download destination | <-- default? | | +--------------------------------------------------------+ NOTE: Depending on the preference settings for "Final Download Location" (doesn't exist yet): Pre-downloaded file segments will be renamed at default location or (if different from current selection) moved from the previous download directory once a destination is chosen (see dialoge below). +- Save As ---------------------------------------------+ | ____________________ | | Recently used directories: |____________________|\/| | <-- bug 24625 :) | ----------------------------------------------------- | | __________________ | | Save in: |_MyDownloads______|\/| [^] [Favorites] | <-- bug 115981 :) | +---------------------------------------------------+ | | | files (or favorites) listed here | | | | | | | | | | | | | | | | | | | +---------------------------------------------------+ | | ______________________________ | | Pre-downloading File ||||||||____37_%_______________| | <-- this bug :) | | | The predownloaded file will be moved to the path and | | filename you select once you click SAVE; or deleted | | if you click CANCEL. | | | | [ CANCEL ] [[ SAVE ]] | +-------------------------------------------------------+

nsbeta1+/adt2 per the nav triage team.

*** Bug 141991 has been marked as a duplicate of this bug. ***

*** Bug 180510 has been marked as a duplicate of this bug. ***

*** Bug 186814 has been marked as a duplicate of this bug. ***

reassigning

Has there been any progrss on this issue yet? I for one would like to see that the initial download can start in the temp directory. However, once the final download location is known and the user hits [OK] the file is moved out of the temp directory to the desired location and renamed to the approprite filename.

Has there been any progrss on this issue yet? I for one would like to see that the initial download can start in the temp directory. However, once the final download location is known and the user hits [OK] the file is moved out of the temp directory to the desired location and renamed to the approprite filename.

joseph: that was fixed in bug 55690 for 1.7alpha

*** Bug 279478 has been marked as a duplicate of this bug. ***

I have a couple ideas to prepose: 1.) Dangerous file extension downloads should by default be blacklisted from being pre-cached. ( also, see 5.) ) Firefox unnessesarily pre-emtively brings up Norton Antivirus when the link to download is clicked, but before clicking Yes or No, and this throws the file from the temp directory into the quarrantine. (Side question: Does this break the ability to even download the file after the temp file is moved to quarantine?) 2.) Only user-initiated download prompts should pre-cache. In other words, automatic download prompts on websites (usually virus material) that don't require a click should NEVER pre-cache, regardless of file extension. 3.) When this preposed option "to pre-cache downloads using memory instead of the hard disk" is selected, there should be a file size ceiling setting. This way, ram is not filled up accidently by large files. 4.) The pre-caching directory should be user-choosable. One benefit of this is if the download directory is the same as the pre-caching directory, no file movement is required. 5.) There should be white and blacklist capabilities regarding pre-caching certain file extensions when prompted to download.

Also, downloads where the source filesize is not known should not pre-cache into the *memory*.

*** Bug 279791 has been marked as a duplicate of this bug. ***

*** Bug 280343 has been marked as a duplicate of this bug. ***

i get same problum and if it virus on a website it **** me off

Just curious, is this the mechanism which allows the file to mostly download while I am busy finding the right folder to save it into? If so, how come this does not work in Seamonkey ("Suite") nightly trunk builds? Or is that exactly what this bug is about?

Just curious, is this the mechanism which allows the file to mostly download while I am busy finding the right folder to save it into? If so, how come this does not work in Seamonkey ("Suite") nightly trunk builds? Or is that exactly what this bug is about? And, shouldn't the target be changed, since we are now beyond that? There should be a flag which gets hit if a target gets missed, so the bug gets additional attention.

"WFM"? "WONTFIX"? What is the status on this?

By "meta bug", I meant that it is intended only to track other defects, most of which have been resolved. I have not been following this bug; so any status should probably come from triage.

As a meta-bug with open dependencies, we might just keep this open. The dependencies might well need investigation, but at the moment we're not explicitly triaging old bugs.

There's no such thing as an "old bug". It is either open or closed. Should this just be marked "WONTFIX"?

(In reply to Worcester12345 from comment #33) > There's no such thing as an "old bug". More precisely, everything filed before June 2016 is out of scope of our formal triage process. > Should this just be marked "WONTFIX"? Not now.