191239 - Downloaded files opened with a helper app are deleted on quit

Status: NEW

(Firefox :: File Handling, defect)

Description

[Simon Fraser [no longer active]]

It's insane that downloaded files that you open with a helper app are deleted
when mozilla quits.

Scenario:
1. User downloads a PowerPoint file (say, received as a mail attachment), and
   says to open it with the helper app (PowerPoint).
2. User spends several hours editing the presentation, saving changes.
3. User quits Mozilla. File is deleted.

This seems like serious dataloss, with abolutely no indication to the user that
this will happen. It may be fine with .zip files that are expanded by the
helper, but isn't fine for most documents.

On Mac, we turned off this behavior because of the dataloss issues.

Comment 1

[Gabriele Fava]

I agree, while when you save a thing you shouldn't save it in the temp directory
(which is where the application got the file), Mozilla should make a comparison
of the file he saved and the file at the exit before deleting it.

Comment 2

[OstGote!]

the opposite is Bug 63105, Bug 76743; the same problem is for Mailnews and
Thunderbird, see Bug 220808

Comment 3

[Mike Connor [:mconnor]]

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

Comment 4

[Josh Lee]

This is insane, I agree. Why do we copy it to the temporary file at all? Just
save it in the cache and tell the helper to open the file from the cache. This
way the file will not go away immediately, yet will still be deleted eventually
when the cache is full.
(IIRC this is what msie does. On a side note, what happens if the user disables
the cache?)

Comment 5

[John T]

If you're getting a file either by email, newsgroup msg or as a browser download
that is not an exe or zip, Mozilla compulsively treats it as a file to put into
the system temp directory and open it. This happens even with filetypes that are
not registered with the system and have no helper programs to open it.

EVERY file except flash, shockwave and sound files to be processed on the spot
ought to go through the "open or save as" dialog and then through the "save at
location with filename" dialog so the user can control where and with what name
ANY file is saved for later use. This needs to be done with ALL files, not just
zips and executables.

ALSO, in 1.7.x the save-file routine worked like many have previously requested.
When you give a location for saving, the file is saved right in the destination
directory, not saved in the temp directory and moved when completed. The latter
has caused various problems including lack of write permission in the temp
directory and out-of-space problems. In version 1.7.x downloads were started in
the temp directory and the partial download was moved to the destination as soon
as the location/name info was entered. This was what many users requested for a
long time, and it worked well. Then someone put a REGRESSION back into 1.8.x so
downloads go into the temp with a random filename until complete.

Finally, in 1.8, and in versions before 1.7 or 1.6, files were saved in the temp
directory with a random filename, so even if there were a partial file to resume
saving, it was unusable in a later session. If you're doing a 2-hour download on
a dialup connection and your wife demands to use the phone or your ISP
disconnects you, you have to reconnect perhaps with a different IP, and Mozilla
probably isn't able to resume the download. You can't do it with something like
Go!zilla if the partial download has a random temporary name, and you just
wasted an hour or so of downloading time.

So go back to the downloading code in 1.7.x and then fix it so all files go
through the "save or open" and then the "location and filename" dialogues, and
save files directly to the destination directory.

Comment 6

[Blake Ross]

I agree that this really does feel like serious data loss. I've done it plenty
of times.

Comment 7

[OstGote!]

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

Comment 8

[Marc Bejarano]

re: comment #0 saying that the behavior is different under OSX by design, i
don't think the application should behave differently on different platforms. 
filed bug 302664 as an enhancement request to create a pref to allow the user to
choose the behavior.

Comment 9

[Michael (GoodWill)]

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

Comment 10

[Josh Lee]

Can someone please explain why the mac behaviour is different? It seems *much*
more convenient for downloads to be saved with a normal filename in the
downloads folder than with a random filename in the temp folder.

Comment 11

[Marc Bejarano]

josh: re: comment #10, i'm a bit confused about what you want.  i think you want
the PC to behave the way the mac does, ie files hang out with their original
filenames in your downloads folder (usually the desktop) forever.  am i correct?
 in any case, it seems that some users like one behavior and others prefer the
other.  i think the best behavior would be to give users of all platforms their
choice of either bahavior. see bug 302664.

Comment 12

[Josh Lee]

Say you open a PDF file with a helper app, then close firefox, then close the 
helper app. If you want the file back, it's much nicer for it to be there on the 
desktop than to have to start firefox again.

Or for another case, suppose you click "Open" when you meant to click "Save". In 
some circumstances, trying again to "Save" may even result in the file being 
downloaded a second time! This way, the file is always downloaded and saved just 
once.

I think having a preference for this would be an okay solution.

Comment 13

[mozilla]

I just lost a document this way, but I think the behavior of deleting the file is correct, the only problem is that the user can edit the file at all; Firefox should save temporary files as 'read only' (mode 400 on unix) so the user cannot edit them and therefore will be prompted when he/she tries to overwrite the temporary file that will soon be deleted.

Comment 15

[Shawn Wilsher :sdwilsh]

Code in uriloader/exthandler is what handles this.  There is a pref you can set to make it not delete the files on exit, and that is "browser.helperApps.deleteTempFileOnExit".

Comment 17

[Dave Yorke]

I (vulgar noob) agree that setting read-only is a great idea.  This should force users to find a proper location and name for a file that they care enough about to edit and save.

I'd also suggest that rather than deleting that files are moved to trash/recycle bin/whatever is appropriate for environment when the browser closes.  This should make them more easily recoverable and still allow users to easily rid themselves of unwanted files when space runs short. (I believe just about every OS/environment tells you to "empty trash" or its equivalent when space runs low.)  If they are all saved to a mozilla specific temp folder then bug 76743 would be satisfied as mozilla could attempt to move any files it finds there every time it quits.

I think a more robust set of prefs for helper file saving location and "disposal" might not be amiss either. I think this properly emphasizes the unique nature of helper app files.  They aren't cache fodder, but they aren't quite as inviolate as downloads. They should be treated as unique (until someone invents the God-browser that can handle any filetype).

Again, I know I'm a noob, so feel free to completely ignore me.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 20

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.