If helper application isn't available anymore downloaded temporary files aren't deleted on shutdown

NEW
Unassigned

Status

()

Firefox
File Handling
--
major
10 years ago
2 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

({privacy})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

Created attachment 297944 [details]
mimetypes.rdf with unaccessibly helper application

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008011804 Minefield/3.0b3pre

When using helper applications for special file types these files have to be downloaded into the temporary folder before the helper application can open them. Normally these files get deleted when you shutdown Firefox. But this doesn't happen if you have configured a helper application for a file type which isn't available anymore. Lets say the user has deleted the application or moved it to another folder on disc. In such a case the temporary downloaded file stays forever inside the temporary folder.

I attach a sample mimetypes.rdf which only needs to be copied into an existing or fresh profile folder. Afterwards start to download a zip file like that one from the URL. The file will be downloaded and an error message appear that the helper application cannot be found. Close Firefox and watch the temporary folder. The file moblpdfs.zip doesn't get deleted.

You can also reproduce this issue when doing the following steps:

1. Create a fresh profile
2. Click the above URL
3. Chose an helper application and set automatic mode
4. Delete or move application to another folder
5. Start download again
Flags: blocking1.9?
Seems like this might be a regression from bug 399563. nsExternalAppHandler::Cancel, called from nsExternalAppHandler::OpenWithApplication, used to remove the temp file if (action != nsIMIMEInfo::saveToDisk).

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.361&mark=2082#2036

Comment 2

10 years ago
Ed can you take a look?
Assignee: nobody → edilee
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
The code in question is here:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.361#2036

I'm not sure if Edward or I are good people to play with this since we both have macs that don't delete the files anyway...

Comment 4

10 years ago
There's this comment in the download manager:

"The underlying transfer creating the file doesn't delete the file because it can't distinguish between a pause that cancels the transfer or a real cancel."

Assuming that's the expected behavior of exthandler, the code path for launching the helper app that fails would need to delete the file because it knows it's canceling and not pausing.

Where is this file? Is it the nsHelperApp js?

Comment 5

10 years ago
Is there a message shown when it tries to open the file with the selected app?

Also, is it a problem that files are left in the temp directory, which the OS should be cleaning when it needs to?
(In reply to comment #3)
> I'm not sure if Edward or I are good people to play with this since we both
> have macs that don't delete the files anyway...

Shawn, there is a global pref which controls the deleting of files on exit. You only have to set browser.helperApps.deleteTempFileOnExit=true and even under OS X the files get deleted.

(In reply to comment #5)
> Is there a message shown when it tries to open the file with the selected app?

The dialog reports that the assigned helper application cannot be found. You don't have an option to select another one. It just cancels the action.

> Also, is it a problem that files are left in the temp directory, which the OS
> should be cleaning when it needs to?
 
Especially on OS X yes. The default temp folder is set to the desktop. As I have seen in the past a lot of people don't want to get cluttered their desktops with temporary files. There is no easy way to change this directory anymore. And the desktop doesn't get cleared-up even with the above pref set.

Comment 7

10 years ago
(In reply to comment #6)
> The dialog reports that the assigned helper application cannot be found. You
> don't have an option to select another one. It just cancels the action.
So this is when you're starting the download -- not when the download finishes and fails to open the app?

badApp=The application you chose ("%S") could not be found.  Check the file name or choose another application.

That one?

So it should be this piece of code?

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in&rev=1.58&mark=834-855#833

"852 // Leave dialog up." ??
(In reply to comment #7)
> So this is when you're starting the download -- not when the download finishes
> and fails to open the app?

No, this happens *after* the download has finished.
 
> badApp=The application you chose ("%S") could not be found.  Check the file
> name or choose another application.

Correct. 

> "852 // Leave dialog up." ??

No idea what that means. But another question:

 849 // Clear chosen application.
 850 this.chosenApp = null;

That only seems to be set for the current action? Shouldn't we reset the helper app at all if it cannot be found anymore?
Flags: tracking1.9+ → wanted-next+
Can we have an update for this bug?
(In reply to Henrik Skupin (:whimboo) from comment #9)
> Can we have an update for this bug?

Ping again after 3.5 years. Can we do something about it?
(In reply to Henrik Skupin (:whimboo) from comment #0)
> When using helper applications for special file types these files have to be
> downloaded into the temporary folder before the helper application can open
> them. Normally these files get deleted when you shutdown Firefox.

Let's go back to the assumption that the file should be deleted. I honestly don't remember that ever being the case for when the file is opened. For example, if I download a DMG and have it automounted (or a zip, auto-unzipped), the original files are kept. And that's how I expect it to be. Imagine it's a PDF for your passport application that was generated online instead...
There is a difference in selecting "Save Link as..." or just clicking on the link to get e.g. the PDF opened in an external application. The former should never delete the file, that's out of question. But the latter, and especially when we are failing to locate the selected helper application, should not keep the files around on the disk. We even display a nice alert so the user knows that something went wrong.

Resetting assignee because it looks like that Edward will not work on it.
Assignee: edilee → nobody
(In reply to Paul O'Shannessy [:zpao] from comment #11)
> Let's go back to the assumption that the file should be deleted. I honestly
> don't remember that ever being the case for when the file is opened. For
> example, if I download a DMG and have it automounted (or a zip,
> auto-unzipped), the original files are kept. And that's how I expect it to
> be. Imagine it's a PDF for your passport application that was generated
> online instead...
IIRC, that's only the behavior on OS X.  On all other platforms we delete.

Updated

2 years ago
Component: File Handling → File Handling
Priority: P3 → --
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.