Firefox crashes upon KDE shutdown

RESOLVED WORKSFORME

Status

()

Core
Widget: Gtk
--
major
RESOLVED WORKSFORME
8 years ago
a year ago

People

(Reporter: Matti, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DUPEME])

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100401 SUSE/3.6.3-1.2 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100401 SUSE/3.6.3-1.2 Firefox/3.6.3

This seems like a regression (worked till some weeks ago, maybe started with 3.6.0
I'm using KDE 4.3.5 on openSUSE 11.2 with all updates.
I set my KDE to restore all previously open applications which works with firefox to the extent that firefox starts, but it always presents the restore tabs screen where I have to click on restore to actually get the last session.
This is very annoying as it defeats the KDE session management and I don't always want to click on restore (and sometimes I click the wrong button in a hurry and I lose all my tabs...)
This was working for a long time now before 3.6 and should be back

Reproducible: Always

Steps to Reproduce:
Keep Firefox open and restart the computer


Actual Results:  
Upon restart, FF opens again but presents the 'restore tabs' screen

Expected Results:  
Firefox should not have crashed and thus automatically restored the last tabs
Do you have Firefox set to automatically restore your tabs? Or does it prompt about saving tabs upon quitting?

If it's the latter, then this is a dupe of bug 506114. If you don't have any prompts blocking Firefox from quitting cleanly, then this a bug somewhere else in Firefox (in which we don't handle the quit message properly).
Whiteboard: [DUPEME]
(Reporter)

Comment 2

8 years ago
No, there is no prompt upon quitting and I've configured FF to automatically restore my tabs.
The Problem is, that it appears that FF is not closing correctly and thinks it has crashed.
This was working in earlier on. Could also be an integration problem with KDE ..?
(In reply to comment #2)
> Could also be an integration problem with KDE..?

Appears to be so. I don't know enough about how all that works. Presumably we're not handling a shutdown message from KDE/Gnome/the OS properly (I've seen a similar bug for Gnome, thus the generalization).

Regardless, It's not really a session restore bug, so lets try to move this to a better component.
Component: Session Restore → Widget: Gtk
Product: Firefox → Core
QA Contact: session.restore → gtk
Duplicate of this bug: 566212

Comment 5

7 years ago
Warning: Restoring of tabs, and apparently retained data is no indicator of closing correctly. It still dies early.
Which can be seen by other things not being restored.

Most thing in Firefox seem to be saved to disk instantly. Like bookmarks, etc.
But some are only saved at exit.
And all those things are lost, when you log out of KDE and KDE kills it.
While they survive when the thing is closed normally.
Of course this also includes periodically saved things, where the changes since the last period are gone. (Shortly before shutdown created tabs were a problem here once, I think.)

And this is the case since at least 3.5.10 (or what was the pre-last release of 3.5?), as that’s when I started using KDE (yes, weird timing), and it was already a problem back then.

By the way: I once took a look at KDE’s code for session saving, and it’s their fault. Firefox is going to the "legacy session" branch, and there they simply kill everything that hasn’t terminated after 10 seconds. Which, when there are many big apps open (in my case Firefox, Thunderbird, two 1GB-VM-usage Java apps, Kopete, Krusader, and all the internal KDE services and stuff [like plasma, klauncher, klipper, etc]), is definitely not enough.

I think the timeout should be *at least* two minutes. As it’s meant for emergency, when an app won’t die. And some take quite some time to shut down. (Like Java and Mozilla ones, but also things like NetBeans or other big suites.)

Comment 6

5 years ago
Matti still see this when using a current version?
Flags: needinfo?(bugzilla)
Keywords: regression

Comment 7

4 years ago
I still see this bug.
Depends on: 694570

Comment 8

3 years ago
Firefox used to be treated as a "legacy session" app by ksmerver, but I think firefox fixed this some time ago - perhaps this was bug #508986 ? Or perhaps this is "solved" by installing libgnome(-ui) - but see bug #694570.

With libgnome & libgnome-ui installed there's still an intermittent problem, particularly when firefox has lots of open tabs/windows.

I've been trying to understand this on my machine and found that that sessionstore.js and sessionCheckpoints.json is not always fully written by the time firefox exits. So firefox history from the last few seconds before logging out could be lost, and the restore tabs screen could appear.
These writes set AsyncShutdownBlockers for the phase profile-before-change (either directly or indirectly); in the normal quit case, firefox waits for all AsyncShutdownBlockers to resolve before exiting, but this doesn't appear to be true when quitting on request of the session manager.

So toolkit/xre/nsNativeAppSupportUnix.cpp:save_yourself_cb or die_cb should make sure that one of them (or their callees) NotifyObservers() of "profile-before-change". Possibly they should also wait for "profile-before-change2" (for telemetry) or "web-workers-shutdown" (to guarantee all IO is complete, though I don't really know whether this is needed)

I think fixing this problem is orthogonal to replacing libgnome(-ui) as in bug #694570 - I don't think that the suggested patch in that bug addresses this, though I could be wrong.

Comment 9

3 years ago
(In reply to Oliver Henshaw from comment #8)
> Firefox used to be treated as a "legacy session" app by ksmerver, but I
> think firefox fixed this some time ago - perhaps this was bug #508986 ? Or
> perhaps this is "solved" by installing libgnome(-ui) - but see bug #694570.

For me, installing libgnome-ui (and dependencies) appeared to fix the problem.

Comment 10

2 years ago
can we get this working without libgnomeui? it’s a minor annoyance but still…

Comment 11

2 years ago
Now that Firefox 46 has migrated to GTK3, it seems that the support of XSMP (for saving/restoring the session) is gone. So now Firefox is killed by the desktop (SIGHUP in my case) instead of interacting with the session manager for a proper termination.

Previously, when GTK2 was used, Firefox used "libgnomeui" (if present) to talk to the Session Manager.

Alternatives are mentioned in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=694570#c0 (bug "Stop using libgnome and libgnomeui on Linux").

I tried to think about a workaround (ex: creating my own helper program that would support XSMP, would notify Firefox to quit and would wait for Firefox process to be terminated), but I don't know how to notify Firefox (without writing an extension) so it stops gracefully (Signals are not supported: https://bugzilla.mozilla.org/show_bug.cgi?id=365749 "respond to SIGHUP in a more intelligent way"; wmctrl allows closing one window, but that is not what I need).

Comment 12

2 years ago
nice! with bug 694570 fixed, this should automatically be fixed as well, right?

Comment 13

2 years ago
(In reply to flying sheep from comment #12)
> nice! with bug 694570 fixed, this should automatically be fixed as well,
> right?

Sebastian, do you agree?
Flags: needinfo?(bugzilla.mozilla)

Comment 14

2 years ago
(In reply to flying sheep from comment #12)
> nice! with bug 694570 fixed, this should automatically be fixed as well,
> right?

At least on my side (as a user, not as a code reviewer) it looks fixed.
(Reporter)

Comment 15

2 years ago
I just uninstalled libgnomeui and it still works. So assuming this doesn't rely on any other gnome lib (which I cannot uninstall completely due to other dependencies), it appears to be fixed for me.
Thanks Matti and Fabimaru
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(bugzilla)
Flags: needinfo?(bugzilla.mozilla)
Resolution: --- → WORKSFORME
I can still reproduce this on Ubuntu 16.10. Every time I shutdown/reboot, Firefox shows me the post-crash page.

Comment 18

a year ago
(In reply to Reuben Morais [:reuben] from comment #17)
> I can still reproduce this on Ubuntu 16.10. Every time I shutdown/reboot,
> Firefox shows me the post-crash page.

Can you file this as a new bug (and link it here) please? I'd like to know the firefox version and the plasma-workspace version you have installed. Can you also test whether it happens when you log out and back in, or just when you shutdown/reboot?

There's some logging options to turn on that might help me understand your problem, but a good place to start is by putting:

[Rules]
ksmserver.debug=true

in ~/.config/QtProject/qtlogging.ini (which won't take effect until the next time you log in). (The logs will be written to either ~/.xsession-errors or to the journal. If it's the journal, you can do "journalctl -b -1 | grep ksm" to see relevant errors from the last boot; otherwise you'll need to switch to another VT and login to the console after a reboot to grep the log, as iirc the .xsession-errors file is recreated on every graphical login.)
Flags: needinfo?(reuben.bmo)
Sorry, I followed a long chain of bug references and RESOLVED DUPLICATEs and ended in this bug, but I'm not running KDE, I'm on Ubuntu 16.10 with Unity.
Flags: needinfo?(reuben.bmo)

Comment 20

a year ago
(In reply to Reuben Morais [:reuben] from comment #19)
> Sorry, I followed a long chain of bug references and RESOLVED DUPLICATEs and
> ended in this bug, but I'm not running KDE, I'm on Ubuntu 16.10 with Unity.

In that case, could you file a bug with ubuntu and link it here? Please include the firefox version (at least firefox 50, right?) and test logging out and back in without rebooting.
Flags: needinfo?(reuben.bmo)
Sure, here it is: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1662281

And yes, I'm on Firefox 51, and it does happen on logout, although not every time.
Flags: needinfo?(reuben.bmo)
You need to log in before you can comment on or make changes to this bug.