Created attachment 469810 [details]
Proposed patch

+++ This bug was initially created as a clone of Bug #630052 +++

Description/reproducer steps/additional info edited.

Description of problem:

gnome-session fails to save desktop sessions, incorrectly collapse apps from many workspaces into a single workspace, loses positional placements.

Version-Release number of selected component (if applicable):

gnome-session-2.28.0 (and later)

How reproducible:

Always

Steps to Reproduce:

1. Enable metacity debugging by setting the env var "METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1", for example using a script in /etc/profile.d/

2. Log in in GNOME, start a few session managed applications on different workspaces, different positions

3. Make sure to enable saving sessions with "gnome-session-properties" by enabling "Automatically remember running applications when logging out"

3. End the GNOME session

4. Log in again in GNOME
  
Actual results:

All windows are restored on the first workspace and the initial position is not restored.

Expected results:

A saved session, apps restored to their original workspaces and correctly positionally placed.

Additional info:

I believe this is an upstream bug.

What happens is that metacity uses the same session state file each time, named after the SM client-id which remains the same across sessions:

SM: Phase 2 saveSM: Saving session to '/home/ofourdan/.config/metacity/sessions/10c1255ad91a092ac129198879916898400000020420025.ms'
...
SM: Exiting at request of session manager

The discard command is:

:X-GNOME-Autostart-discard-exec=rm -f /home/ofourdan/.config/metacity/sessions/10c1255ad91a092ac129198879916898400000020420025.ms

(this is in the desktop file for the session, as found in ~/.config/gnome-session/saved-session/*.desktop)

So gnome-session removes the previous session state file saved by the applications after each application has saved its state but because metacity uses the same file, its state file is removed by the session manager and the state is not restored (thus the position and workspace of running windows is not restored):

The problem appears with that commit upstream:

http://git.gnome.org/browse/gnome-session/commit/?id=3e346957cebcbf9e747757d2d649329266743afc

The order of events is as follow (observed by enabling debug logs in both
metacity and gnome-session):

1. Session terminating
2. Session manager sends a SaveYourself to all clients
3. metacity gets the SaveYouself message, save its state file and replies
SaveYourselfDone
4. Session manager gets SaveYourselfDone
5. Session manager checks for the given discard_exec command in hash table in
gnome-session/gsm-session-save.c gsm_session_clear_one_client()
6. Session manager does not find the discard_exec in hash table so it runs the discard_exec command, thus removing the state-file in gnome-session/gsm-session-save.c gsm_session_clear_one_client()
7. Session manager adds the discard_exec to the hash table in save_one_client()

So the discard command is never found in the hash (being empty) because the hash is populated after the removal...

gsm_session_save()
  |
  +-> gsm_session_clear_saved_session()
  |     |
  |     +-> gsm_session_clear_one_client()
  |           |
  |           +-> g_hash_table_lookup (discard_hash, discard_exec) ?
  |               FALSE => g_spawn_async (discard_exec)
  |
  +-> save_one_client()
        |
        +-> g_hash_table_insert (data->discard_hash, discard_exec, discard_exec);

The patch here attached does the things differently, it actually populates the
discard_hash with the existing (old) discard commands, then save the session
and removes the old discard command only if not found in the hash.

This way, if the old and new file are identical, the file is not removed by the session manager.

With this patch, gnome-session and metacity behave as expected. It is also possible to change metacity (see the patch proposed in bug 643450) yet I think this is really a bug in the session manager (rather than metacity).