Crash when closing firefox after "open with" and having still opened the file

[Jan Niklas Hasse]

1. Click on a .deb link
2. Select "open with package installer"
3. click install package after downloaded
4. close firefox (because you don't need it anymore)
5. Enter your password for sudo
6. package manager crashes because the deb file was deleted in the moment you closed firefox

[John Vivirito (gnomefreak)]

Can you please attach the crash report in /var/crash to this bug report

[Jan Niklas Hasse (jhasse)]

It crashes because the file gets deleted. So Firefox should not save this file in /tmp.

Just try out yourself and you will see what i mean. This can be easily reproduced by following to the steps above.

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Thank you for the bug report however this report lacks information we need to investigate it further. For this reason, we are now going to close the bug - please feel free to reopen when you have more information at hand.

Further information can be found at [1]

[1] https://wiki.ubuntu.com/MozillaTeam/Bugs

[Jan Niklas Hasse (jhasse)]

Well i think i made a mistake: It's not crashing, it gets stuck. After following the steps the package manager will be grey forever.

[Pino Toscano (pinotree)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.8.1.14) Gecko/20080404 Iceweasel/2.0.0.14 (Debian-2.0.0.14-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.8.1.14) Gecko/20080404 Iceweasel/2.0.0.14 (Debian-2.0.0.14-2)

(See steps.)

Reproducible: Always

Steps to Reproduce:
Suppose to open a remote link in a webpage using an application selected in the "open with/save" dialog. Then Firefox downloads the remote file to a temporary location (and IMHO it should be a bit more smart, but this is bug #415441 already), and launches the application with the downloaded file. Good so far.
Then, if we close Firefox but not the application, Firefox removes the downloaded temporary file.
Actual Results:
The application launched for the (temporary) file can have troubles if it wants to still make use of the file.

Expected Results:
Firefox should not implicitely remove the temporary file, but for example:
- leave it around, either permanently or tracking the application launched with fork() [UNIX, of course]
- manage explicitely it in the downloads, just like Opera does

This was reported as problem in KDE's bugzilla for the KDE 4 application Okular:
  http://bugs.kde.org/show_bug.cgi?id=163363

If the users (after doing the steps before, eg fire Okular from Firefox and close Firefox) selects "Save copy as", they are not able to save it, because the only reference to the file (the temporary file, not even the remote URL that basically all the KDE applications can manage) is gone.

Can also be reproduced with Firefox 3beta5:
  Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

[Matti-mversen (matti-mversen)]

I don't know the situation on on linux but i expect that the temp file is locked by the helper application and Firefox should not be able to delete this file.
Firefox itself must try to delete the file to clear the temp directory.

[Pino Toscano (pinotree)]

The helper application could also have no need to keep the file open all the time, for example by reading and "digesting" it all at once. But then, in case it wants to access it again for any reason you can think about, and Firefox was closed in the meanwhile, here the problems come.

Confirmed also with Firefox 3.0rc2:
  Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008052912 Firefox/3.0

[Jan Niklas Hasse (jhasse)]

Here's a video showing the bug: http://watteimdocht.de/jan-nik/bug.ogg

It should be reproducible, be sure it's the last firefox window you close.

[Jan Niklas Hasse (jhasse)]

Can I somehow reopen this bug?

[Jan Niklas Hasse (jhasse)]

Here's a second video which shows this bug in action on Intrepit:
http://watteimdocht.de/jan-nik/bug2.ogg

Can this please be fixed? It's really annoying.

[John Vivirito (gnomefreak)]

I would really like someone from mozilla team to confirm this happens, I cant reproduce this.

[Jan Niklas Hasse (jhasse)]

There you go: https://bugzilla.mozilla.org/show_bug.cgi?id=437767

[Alexander Sack (asac)]

confirming. not sure what we really want, but the temp file removal was communicated as being evil to be multiple times. not sure how evil leaving those files in $TMP would be perceived. at least debian/ubuntu clear $TMP by default on reboot so it might be ok.

[Matti-mversen (matti-mversen)]

win32 doesn't delete the file and the helper applications are holding a file lock open on this files. I'm unsure about OS X.
Leaving them in temp is no alternative solution for every os that doesn't delete the temp files. Some users will end with gigabyte of wasted space.

It might be the best solution on Debian/ubuntu but what about Suse or Fedora ?
Deleting on every reboot can be something that is not fast enough if you never reboot your linux system and the user downloads several iso files every day and opens them with a DVD-Burn application. (worst case scenario)

Maybe watch if the helper application process is gone and delete it after that ?

[Alexander Sack (asac)]

resurrecting now that we have a upstream bug.

[Jan Niklas Hasse (jhasse)]

This really annoying as it happens to me almost every month. Please fix this!

(In reply to comment #4)
> Maybe watch if the helper application process is gone and delete it after that
> ?

That might not work in all cases, since the helper application might execute other processes that need the file.

(In reply to comment #4)
> It might be the best solution on Debian/ubuntu but what about Suse or Fedora ?
> Deleting on every reboot can be something that is not fast enough if you never
> reboot your linux system and the user downloads several iso files every day and
> opens them with a DVD-Burn application. (worst case scenario)

Who cares? I don't now anyone who opens his iso files with DVD-Burn application right away. And I also think it isn't firefox business to clean up temporary files.

[Jan Niklas Hasse (jhasse)]

Any progress on this one? Sorry for the spam, but I can't understand why I am the only one frequently running into this bug (even on Windows!).

[Jan Niklas Hasse (jhasse)]

Any progress? I think it should be fixed on Linux at least (as the /tmp directory is cleaned up at every boot).

[Paul White (paulw2u)]

Upstream report is still open but I cannot reproduce with Firefox 66 in Ubuntu 18.04.

@jhasse, can this bug report be closed or do you still see the problem tha5t you described?

[Paul White (paulw2u)]

Further to my comment #19, I'm now closing this as fixed due to:

1) No response from reporter after almost one year
2) Not reproducible here using FF 74 and Ubuntu 20.04 (dev)
3) Comment https://bugzilla.mozilla.org/show_bug.cgi?id=437767#c7
by reporter suggests fixed some time ago

[Jan Niklas Hasse (jhasse)]

Sorry, missed your last comment. Yes, I can still reproduce this using Firefox 74.0 and Ubuntu 19.10.

> Comment https://bugzilla.mozilla.org/show_bug.cgi?id=437767#c7
> by reporter suggests fixed some time ago

Sorry my English wasn't clear on that one: I meant "should" in that it ought to be fixed, not that it was fixed.

[Paul White (paulw2u)]

@jhasse, no problem.
Status needs to be reverted to "Triaged".
@osomon?

[C de-Avillez (hggdh2)]

reverting to Triaged per request from PaulW2U.

[Olivier Tilloy (osomon)]

Thanks for the feedback Jan. Unfortunately I'm unable to reproduce the problem.

Which package installer program do you instruct firefox to use to open the downloaded deb?

I've tested gnome-software (the default) but it seems it's unable to handle side-loading debs, and gdebi-gtk, which correctly complains that the file doesn't exist any longer when trying to install it after closing firefox.

[Jan Niklas Hasse (jhasse)]

It was gdebi-gtk, but apparently they fixed the crash.

[Tajizogos (tajizogos)]

Created attachment 9386722
same problem

Thanks from inmachatu1971.