This is even worse if you save your session while running gnome-shell. There are two instances of mutter launched in this case, and the top panel never appears on the screen.

FIxing this properly will probably require to add session management support to gnome-shell itself, or at least a way to detect when mutter is already launched with the proper arguments.

This has changed a bit now that mutter is a library instead of a binary, but the problem still exists.

if you save your session and are in classic mode then when you come back you'll be without classic mode.

This is because the RestartCommand  that is saved into the session fails to include the --mode that gnome-shell was started with.

see also bug 648828

Created attachment 264717 [details] [review]
session: restore command line arguments on session restore

gnome-shell changes behavior dramatically depending on what arguments
it was started with.  Concretely, if it's started with --mode=classic
it loads a completely different user experience than if it's started
without specifying a mode.

Since the command line arguments are an important part of the state
of gnome-shell, those command line arguments really need to be tucked
away on session save.

This commit makes sure to include the command line arguments in the
RestartCommand so state is properly restored.

so i was going to suggest the above, but it doesn't really solve the problem, just flips the coin, I guess. Before if you saved when logged into classic mode you'd end up back in a non-classic session (since --mode=classic was stripped).  Now if you saved when logged into a classic session and try to pick a normal session from GDM you'll end up in a classic session (since --mode=classic is hard coded in the saved session).

I think we're going to need to add better smarts for classic versus non-classic.

Comment on attachment 264717 [details] [review]
session: restore command line arguments on session restore

I think the real answer means not relying on the command line to set the session, since the command line gets saved in the session state and the session type can get changed form log in to log in independent of the saved sessino.

Can we just deprecate and remove session saving?

Since my understanding of my issue has changed so much i'm not not going to hijack this bug anymore.  This report is really just a duplicate of bug 648828

*** This bug has been marked as a duplicate of bug 648828 ***

(In reply to comment #7)
> Can we just deprecate and remove session saving?

Not really, the window manager plays an important part of the XSMP, so dropping  it completely would break XSMP.  Aside from that, i need the feature for RHEL 7 based on customer demand.