Bug 664516 - gnome-session and metacity do not restore windows position or workspace
Summary: gnome-session and metacity do not restore windows position or workspace
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnome-session
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: GSS_6_2_PROPOSED 697582
TreeView+ depends on / blocked
 
Reported: 2010-12-20 16:27 UTC by Olivier Fourdan
Modified: 2018-11-28 21:44 UTC (History)
10 users (show)

Fixed In Version: gnome-session-2.28.0-17.el6
Doc Type: Bug Fix
Doc Text:
Prior to this update, the gnome-session utility may have improperly saved desktop sessions. As a consequence, when logging in, the running applications were incorrectly collapsed from multiple workspaces into the first workspace and their initial position was not restored. This has been fixed: applications are now restored in their original workspaces and correctly positionally placed.
Clone Of: 630052
Environment:
Last Closed: 2011-12-06 16:28:46 UTC
Target Upstream Version:


Attachments (Terms of Use)
Proposed patch (3.05 KB, patch)
2010-12-20 16:27 UTC, Olivier Fourdan
ofourdan: review?
Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 28137 None None None Never
Red Hat Product Errata RHEA-2011:1654 normal SHIPPED_LIVE gnome-session bug fix and enhancement update 2011-12-06 00:50:25 UTC

Description Olivier Fourdan 2010-12-20 16:27:53 UTC
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).

Comment 3 Ray Strode [halfline] 2011-06-09 14:27:02 UTC
Will need to investigate more, but the explanation looks carefully researched and there's a patch. devack+

Comment 5 Dan Thurman 2011-06-14 15:03:39 UTC
(In reply to comment #3)
> Will need to investigate more, but the explanation looks carefully researched
> and there's a patch. devack+

Is this the same patch attached to this bug report
or is it some other patch still under test?

In any case, can I have some instructions on
how I can install this patch, step-by-step so
I can get this folded into my F13, since it is
now EOL or will there be a backport or release
to fix this on F13?

Comment 6 Ray Strode [halfline] 2011-08-02 18:34:00 UTC
This looks like a downstream bug, actually.

We have a patch that does:

  data.discard_hash = g_hash_table_new_full (...);
+ gsm_session_clear_saved_session (..., data.discard_hash);
  
  gsm_store_foreach(..., save_one_client, &data);
  ...
- gsm_session_clear_saved_session (..., data.discard_hash);


So that's pretty wrong, and it's what's causing the behavior mentioned above:

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

from comment 0.

Comment 7 Ray Strode [halfline] 2011-08-02 22:03:09 UTC
Okay, I've corrected the bug alluded to in comment 6 and am building packages now.

Comment 10 Eliska Slobodova 2011-08-12 09:14:38 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, the gnome-session utility may have improperly saved desktop sessions. As a consequence, when logging in, the running applications were incorrectly collapsed from multiple workspaces into the first workspace and their initial position was not restored. This has been fixed: applications are now restored in their original workspaces and correctly positionally placed.

Comment 11 errata-xmlrpc 2011-12-06 16:28:46 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1654.html


Note You need to log in before you can comment on or make changes to this bug.