365749 - respond to SIGHUP in a more intelligent way

Status: RESOLVED DUPLICATE of bug 336193

(Toolkit :: Startup and Profile System, enhancement, P4)

Description

[Frank]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1

When Desktop Managers such as Gnome close (or logout) they send hangup signals (SIGHUP) to running programs, like Firefox. Firefox doesn't respond to SIGHUP. When Firefox is ran again it thinks it crashed last time ran and asks to restore tabs.

Reproducible: Always

Steps to Reproduce:
1. run Firefox
2. run in Terminal: killall -s HUP firefox-bin
3. run Firefox
Actual Results:  
Thinks it crashed last time. Asks to restore tabs.

Expected Results:  
Should run as if closed normally before.

Not present on Microsoft Windows, because Windows doesn't have UNIX signals.

Could just have an empty signal callback for hangup and have it call the function used on close.

http://users.evtek.fi/~tk/rtp/signals-programming.html

Comment 1

[Jesse Ruderman]

I guess this is similar to bug 333907 on Windows.

Comment 2

[timeless]

i'm confused. it seems to me that session restore is *precisely* what you want. and that the only part of the experience you don't approve of is the dialog.

anyway. i absolutely disagree with your expected results.

I expect to have all my tabs restored. And I think I'm not alone.

Comment 3

[Mike Connor [:mconnor]]

I'm not sure this blocks, if there was a way to interrupt shutdown that would be great, but if the OS closes the app without an option to abort, we should absolutely restore data.

Comment 4

[Simon Bünzli]

See also bug 336193 for better SIGTERM handling.

Comment 5

[Daniel Beardsmore]

Timeless: the problem is that by default, Firefox 2 does not restore your last session on load. Thus, tabs should not be restored if the program was safely closed. The bug states "When Desktop Managers such as Gnome close (or logout) ..." which is suggestive of the logical practice of leaving the GUI to close all running apps for you rather than closing them all manually one by one (which is much slower and tedious).

However, logging out of the GUI (be it Windows or X11) does not cause Firefox to exit cleanly, it simply shuts down and this leaves the session restore data behind, unclosed. Next launch, Firefox realises that it was not shut down cleanly and displays the session restore query dialog. If you've instructed Firefox specifically NOT to restore windows/tabs from your last session, this message is rather confusing since to your mind, there was no crash and nothing to restore. Issues of data loss aside, the dialog is meaningless and annoying.

On the other hand, I *DO* have Firefox set to restore all windows/tabs from my last Firefox session AND THE DIALOG BOX STILL APPEARS. Since I SPECIFICALLY STATED that I want tabs restored, why is it asking me if I want my tabs restored? It knows the answer even before asking, so why ask? It's a stupid question.

It's a knotty mess of flaws to be resolved, starting with implementing clean shutdown when the GUI tells the application to close. This will stop the dialog from appearing in the first unwanted case, i.e. the program did not crash. The fact that it appears when session restore is enabled is another problem, but this is a thornier issues, since session restore after a Firefox crash is difficult: what if you re-open the page that caused the crash? Ideally you want to restore all pages BUT that one, and the present dialog does not cater for this. Really, it should be a tick box list where you untick what page you think was the cause, and retry. If you crash again, that page must still be in the list next launch so that you don't lose track of it if you try another page. (In case you are one of those folk who (and I am not kidding here) like opening 10, 20, 50, 100 tabs at once from a bookmark, and one of them triggers a crash -- this has been a recurring crash scenario with the iCab browser, even if your page file is going to burst... ;)

Comment 6

[Jef Driesen]

This is a very annoying problem for me, because the disk cache is cleared after such an unclean exit. I need that disk cache for offline browsing in situations without network connection (e.g. a train).

Comment 7

[Mike Connor [:mconnor]]

Jef, for better or for worse, there's extensions that'll prevent that behaviour...

Comment 8

[Michael Wu [:mwu]]

The fix in bug 93789 should have fixed logout for most unix desktops. Responding to SIGHUP or SIGTERM shouldn't be as high of a priority now, but should it happen.. we should just shutdown cleanly and save the session for next time.

I don't think this is a blocker now since most users don't send SIGHUP or SIGTERM to terminate firefox and the normal case when this used to happen should be handled by the xsmp support provided by bug 93789.

Comment 9

[Eric Toombs]

This one has been annoying me and no doubt many others for quite a while. I thought it was my desktop environment (XFCE) this whole time. XFCE closes programs with HUP on logout, so every time I forgot to shut down firefox before logging out, next time I would open it, it would open in recovery. I can't be alone on this. It's just that most people don't know what piece of software to blame. I doubt XFCE is the only desktop environment that relies on HUP or TERM to close the programs it manages on logout.

So now you know, there are actually quite a few people who albeit indirectly terminate their Firefox with HUP and TERM. We hope you fix this soon.

Comment 10

[Robert Strong (they/them - no direct email)]

Not a shell integration bug. I suspect this would be handled by Startup & Profile system so changing component... specifically
https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportUnix.cpp