Open Bug 129923 Opened 18 years ago Updated 5 months ago

[meta] Bugs related to <pre->saving files to temp dir.

Categories

(Firefox :: File Handling, defect, P5)

defect

Tracking

()

People

(Reporter: trudelle, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: meta)

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.
Status: NEW → ASSIGNED
Keywords: meta
Target Milestone: --- → mozilla1.0
Depends on: 129614
Depends on: 129604
Depends on: 68255, 70915, 82040, 83166, 116132, 129834
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.
Depends on: 128348
Depends on: 55307, 91795
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
Target Milestone: mozilla1.0 → mozilla1.0.1
Depends on: 137676
*** Bug 143843 has been marked as a duplicate of this bug. ***
*** Bug 145978 has been marked as a duplicate of this bug. ***
Depends on: 103877
No longer depends on: 103877
Depends on: 121029
Depends on: 159162
Depends on: 154891
Depends on: 73757
No longer depends on: 159162
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.
Depends on: 135736
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.
Keywords: nsbeta1
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 ]]  |
+-------------------------------------------------------+
Depends on: 172215
QA Contact: sairuh → petersen
Blocks: 157548
nsbeta1+/adt2 per the nav triage team.
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
*** 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. ***
Depends on: 159432
reassigning
Assignee: trudelle → varga
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
Depends on: 196738
Keywords: nsbeta1+
Whiteboard: [adt2]
Depends on: 199473
Depends on: 224692
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.
Depends on: 452461
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Target Milestone: mozilla1.4alpha → ---
Version: Trunk → unspecified
"WFM"? "WONTFIX"? What is the status on this?
Flags: needinfo?(trudelle)
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.
Flags: needinfo?(paolo.mozmail)
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.
Flags: needinfo?(trudelle)
Flags: needinfo?(paolo.mozmail)
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.
Priority: -- → P5
Assignee: jvarga → nobody

This is still a thing?

Summary: Bugs related to <pre->saving files to temp dir. → [meta] Bugs related to <pre->saving files to temp dir.
You need to log in before you can comment on or make changes to this bug.