-> mozilla

after closing the firefox window, open a terminal (konsole) and type the following:

ps -ae | grep fire

Does it report firefox is still running? if so type: 

kill pid (pid being the 1188 number or so). 

Reboot, now what happens?

If I close the window normally (without logging out), firefox quits and is not running any more. So after logging in and out it doesn't try to start again.

Firefox does this when you log out without quitting; rather than automatically restore itself it asks if you would like to restore your last session or start again.

I believe this is by design.

Well, it should IMHO differentiate if it crashed or exited normally (and logging out is the latter obviously).

This is most probably
https://bugzilla.mozilla.org/show_bug.cgi?id=336193

I never checked that yet but I guess closing KDE kills running applications with SIGTERM?

GNOME does the same thing,  Its probably not exiting normally because its not support XSMP where it could just handle the quit signal.

The upstream is https://bugzilla.mozilla.org/show_bug.cgi?id=93789

This is also have of bug 257343.

There is an upstream patch for the mozilla piece thats been comitted to trunk,
not sure if its back portable.  Wolfgang, Maw what do you think

Investigating/testing now.

I integrated the upstream patch into the buildservice Firefox package now and it does something:
- Gnome is not saying that Firefox can't get restored
- Firefox doesn't ask to restore the session
but
- Firefox also doesn't restart in the old state when login to Gnome
  (which I understood should be the point with that)

I don't know much about xsmp and the Gnome layer about it.
Could someone please check the code in 
https://bugzilla.mozilla.org/attachment.cgi?id=272580
and explain if that saves the session correctly on X11/Gnome to be able to restart the browser or is that not intended here?
Looking at metacity's sessions it saves an entry with class="Firefox-bin" name="Gecko" and some more info.
Does metacity try to restore using class as application to start? That would explain why it doesn't work.

(In reply to comment #11 from Wolfgang Rosenauer)
> - Gnome is not saying that Firefox can't get restored

This is the right behavior.  Gnome-session detected that Firefox registered as a session-managed client, so "all is normal".

> - Firefox doesn't ask to restore the session

... as expected, since it has the chance to quit normally from die_cb() in the patch.

> but
> - Firefox also doesn't restart in the old state when login to Gnome
>   (which I understood should be the point with that)

This happens because the patch doesn't provide a "restart command" correctly.  Each session has a unique ID.  Session-managed programs can use this ID to save their information and restore it later (very few programs implement this correctly, if at all!).

[XSMP is pretty baroque... it wants to let you do things like have a session for home, a session for work, etc., all with different programs to be restarted each time.  That's what the different IDs are for.]

If you simply call gnome_program_init(), the machinery gets set up so that the restart_command is basename(argv[0]).  This is a best-effort thing; gnome_program_init() assumes that it is getting the real argv from main().

However, Firefox is passing bogus data for that argv, and it is not setting an explicit restart_command :)  Grep for "gecko" in the patch; you'll see that

+  char *argv[2] = { "gecko", "--disable-crash-dialog" };
+  gnome_program_init("Gecko", "1.0", libgnomeui_module_info_get(), 2, argv, NULL);

is definitely not a valid command line.  If you replace "gecko" with "firefox" in the definition of argv, I'm 99% sure you'll get Firefox to restart, but without restoring its tabs/windows.

Ideally, a program will do the full thing in its save_yourself_cb and do:

  save_my_data_for_session_id (session_id);

  gnome_client_set_restart_command (client, ["myprog", "--session-restart", session_id]);

  gnome_client_set_discard_command (client, ["myprog", "--discard-session-info", session_id]);

These are just sample arguments; they could be anything your app wants.  For example, if your program creates ~/.foo/sessions/[session_id] when saving a session, it could very well set its discard_command to "rm -rf ~/.foo/sessions/[session_id]".

[XSMP is even more baroque than that --- you can define other commands for different situations (resign_command, shutdown_command).  But you don't care about those unless you are a session-wide, desktop-level program.]

> Does metacity try to restore using class as application to start? That would
> explain why it doesn't work.

It's not metacity; it's gnome-session.  See above for how the command gets determined.

Thanks for the explanation.
So the issue described in the subject of this bug is solved now in Firefox from buildservice. It doesn't complain about unexpectedly closes sessions.
So assigning directly to maw to include the patch in the distro.

Seems it is included in 10.3 Firefox

*** Bug 220249 has been marked as a duplicate of this bug. ***