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

Status: NEW

(Firefox :: File Handling, defect, P5)

Description

[Peter Trudelle]

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.

Comment 1

[Peter Lairo]

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.

Comment 2

[Peter Trudelle]

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?

Comment 3

[Bill Law]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 5

[selmer (gone)]

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

Comment 6

[Peter Trudelle]

not sure what list, so ->1.0.1

Comment 7

[gavin long]

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

Comment 8

[Pete Boyd]

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

Comment 9

[Klaus Strebel]

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.

Comment 10

[Brook Harty]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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).

Comment 12

[Peter Trudelle]

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.

Comment 13

[Peter Lairo]

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 ]]  |
+-------------------------------------------------------+

Comment 14

[Paul Wyskoczka]

nsbeta1+/adt2 per the nav triage team.

Comment 15

[Max Kanat-Alexander]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Jan Varga [:janv]]

reassigning

Comment 19

[Joseph Kaye]

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.

Comment 20

[Joseph Kaye]

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.

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

joseph: that was fixed in bug 55690 for 1.7alpha

Comment 22

[Matthias Versen [:Matti]]

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

Comment 23

[mmortal03]

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. 

Comment 24

[mmortal03]

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

Comment 25

[Matthias Versen [:Matti]]

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

Comment 26

[Matthias Versen [:Matti]]

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

Comment 27

[Jay Buck]

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

Comment 28

[Worcester12345]

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?

Comment 29

[Worcester12345]

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.

Comment 30

[Worcester12345]

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

Comment 31

[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.

Comment 32

[:Paolo Amadini]

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.

Comment 33

[Worcester12345]

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

Comment 34

[:Paolo Amadini]

(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.

Comment 35

[Worcester12345]

This is still a thing?