Beware: This problem is masked by Firefox saving most of its changes right when they are done. Important: This bug is not about implementing KDE session manager integration. When Firefox is left running, while logging out of a KDE session, Firefox crashes. I am fairly sure, this is, because Firefox takes longer to exit, than KDE gives it time. When I close Firefox the normal way, I can’t re-start it until I wait some seconds. And when I log out, KDE is back at the KDM login faster, than it would take Firefox alone to exit. Let alone Thunderbird, Sancho, Krusader, Kopete, Skype, and the KDE services. This is bad, because it means data loss, and very bad because Firefox/Thunderbird don’t normally make it clearly visible, and so it’s sneaky data loss. Over time I have no doubt it will cause profile corruption. Reproducible: Always Steps to Reproduce: I’ve found ways to reproduce this though: Firefox: 1. Install All-In-One Sidebar, re-start Firefox 2. Open the sidebar (e.g. the addons list) 3. Re-start Firefox. The sidebar should still be open. 4. Now close the sidebar again. 5. Log out of KDE, and log back in. Result: Firefox restarts, and the sidebar still is open. Expected: If you manually re-start Firefox instead of logging out in point 5, Firefox will re-start with the sidebar closed. Firefox data loss example: 1. Install Tab Mix Plus. 2. In the settings, enable Tab Mix Plus session management instead of the built-in one. This is, because other than the built-in, the TMP one notifies users of crashes. Instead of quietly restoring the tabs. 3. Open some tabs with pages in them. 4. Log out of KDE and back in. Result: TMP session management notifies you of a crash and asks if it should restore the session. Expected: If you had instead closed Firefox normally, it would not have notified you of a crash, and no data would have been lost. It can also be reproduced with any setting that is retained in memory without immediate writing to disk. With a bit of playing around and hunting, especially with add-ons, many of those can be found. Beware that even without any of those, Firefox still crashes and still can have data loss. Unfortunately I don’t know how to enable a kind of logging that survives a crash. In Thunderbird the behavior is the same. The best example of KDE causing data loss can be shown with Java apps. 1. Install Sancho. 2a. In the transfers window change the column order, size, or sorting. 2b. Or: Change anything in Tools → Preferences → sancho: * 3. Log out of KDE and log back in. Result: If the app even restarts at all, the column and preferences changes will be lost. Expected: Just like when manually closing the app and re-starting it, the settings and changes should be kept. Actual Results: See above. Expected Results: See above. Feel free to change the bug title. But keep the possibility for users of Firefox/Thunderbird to find it by searching for e.g. “firefox session” alone. Because of the data loss aspect, I did put the severity to “critical”. Please, please, please, DON’T quickly dismiss this if you seem to have trouble reproducing it. It is definitely reproducible. It just may not be visible. And it can definitely cause data loss. I will help as much as I can, and we will extinguish this bug once and for all. :)
It's hardly critical when the workaround is to simply close the app before you log out.
(In reply to comment #1) > It's hardly critical when the workaround is to simply close the app before you > log out. But it’s critical, if you lose data. That’s what the information next to the dropdown said. I think we can agree, that the whole point of session management is, that you don’t close the programs. So your critique is, that the bug is X causing data loss in Y is not critical, because you simply don’t have to use X? ;)
It is not that critical since as it is said, you can workaround it already. The issue tho is that session-manager does not wait enough time, nor that the apps report over dbus "hey i am working on my quit". I would recommend to report this over at upstream bugzilla [http://bugs.kde.org/] where the right guys (dunno who is taking care of this part of kde) might advise some neat hack or actualy fix the code to be correct.
Did some research and I believe this is what upstream says: https://bugzilla.mozilla.org/show_bug.cgi?id=557601 https://bugs.kde.org/show_bug.cgi?id=273326 Would like to see this fixed, as well.
(In reply to comment #4) I know, I reported that KDE bug. ^^ Just to take the key bit out of the links, here’s my last comment at the Firefox Bugzilla: > 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. And the KDE guys apparently don’t care. At all. They just murder every child that hasn’t left the class room after 10 seconds. So I guess the only solution is to patch ksmserver to a different timeout… :( But seriously… 10 seconds and no warning, no “Would you like to wait a little longer or kill them off?”? What are they thinking? Even Windows does that.
Can you test with kde 4.7.2?
(In reply to comment #6) > Can you test with kde 4.7.2? I will. I’ll check back with the results tomorrow. (Can’t reboot today.)
By the way: A really easy way to reproduce this: Preparation: 1. Install the “All-in-One Sidebar” add-on. (Might work without it, but I’m not sure, so I tell you what works here.) 2. Restart Firefox. 3. Click on one of the sidebar icons, like the downloads one. 4. Leave it open, and restart Firefox. Result 1: Firefox starts with the downloads sidebar still open. (Which is the correct behavior.) Real restart: 5a. Close the sidebar. 6a. Close Firefox and restart it. Result 2a: The sidebar stays closed when Firefox starts. (The same way it remembered the state in Result 1.) Restart via the KDE session management: (Start from Step 4 again.) 5b. Close the sidebar. 6b. Log out of KDE without closing Firefox, and log in again. Result 2b: The sidebar is open again. (Or in other words: It is still open, since Firefox couldn’t save the fact that you closed it in step 5b.) Result 2a and 2b should logically be the same. This works in Thunderbird too. (Maybe not with the sidebar extension, but others. One example is if you update Thunderbird, it usually shows a new tab, informing you of the update and what changed. Closing that tab is the equivalent of step 5 in Thunderbird. It always comes back, unless you restart TB manually.) Same thing with other programs with that problem, like Sancho. NOTE: I still have to do the test with KDE 4.7.2, to check if this doesn’t happen anymore. But I’m pretty sure it will. I’m doing exactly the thing described above to test it, by the way. So we’ll see tomorrow.
Ok, the results, as promised: This will surprise you… Only Thunderbird kept its state (Result 2a). Both Firefox and Sancho (Java) forgot it, and started with result 2b. To be honest, I think this is a race condition / timing thing. Some win, some are too late and lose. So I add “Have multiple large applications open, that together will take a long time to close.” as a requirement for reproducing this. At least I've got a fine easily and reliably reproducible example now. Is there anyone looking into this, by the way?
By the way: I think the only workaround I can offer right now, is to make a shell script that terminates your fat applications the normal way, waits for them to have exited, logs them into a file, puts its sister script into the autostart folder, and *then* calls KDE’s impatient log out / shutdown / reboot command. So that that sister script can run them at start again. Which of course is, what KDE’s script should be doing in the first place, and every other DE/OS already does.
(In reply to comment #10) Oh, don’t forget to add a timeout to that script that *only warns the user*, so that he can decide whether to wait some more, or kill one problematic application right now.
Thanks all. KDE SC 4.9.1 is now in tree. Sync in some hours to get the change. + 04 Sep 2012; Johannes Huber <johu@gentoo.org> +ksmserver-4.9.1.ebuild: + Version bump KDE SC 4.9.1
(In reply to comment #12) Unfortunately they just added a way to change the timeout. Not the expected warning dialog for when a program doesn’t exit, that would let you *decide* if you want to wait longer or just kill them. :/ I personally have given up on expecting further sanity from there. I’ll just have to wait until my own graphical shell is finished.
News: 1. This also happens with “killall -s TERM firefox". Firefox apparently just loses its pants and closes without saving state even on normal SIGTERM. 2. This is also a *Firefox* bug. 3. It is definitely not fixed. But as I said: I’m not gonna fight the insanity of a certain strain of developers (KDE Plasma / Gnome / iOS / Windows Metro / WhatWG nuthouse) any longer.
