Bug 1272442

Created attachment 1083636 [details]
1) journalctl during the logout

Created attachment 1083637 [details]
2) journalctl during the subsequent login

This is not something that can be addressed as a 7.2 blocker. It has been the same way in 7.0 and 7.1, marking it as a regression towards the end of the 7.2 blocker phase seems disingenuous.

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

So i've been looking into this a bit.

- The first problem I ran into is the "save" button in properties doesn't work right.  I guess that's why comment 0 suggests turning on auto save and logging out, rather than saying to use the save button.  That problem is easy to fix though, it just a needed a small change to handle the SaveSession method.

- The second problem I ran into is that apps don't register with the session manager by default.  Gtk has code to register, but only if apps opt in with "register-session=TRUE" in their GtkApplication singleton instance, and most apps don't set it.  Fixing this requires a change in every app we care about supporting this feature.

- The third problem is gnome-session doesn't actually support saving for modern apps:

static GKeyFile *•
dbus_client_save (GsmClient *client,•
                  GsmApp    *app,•
                  GError   **error)•
{•
        g_debug ("GsmDBusClient: saving client with id %s",•
                 gsm_client_peek_id (client));•
•
        /* FIXME: We still don't support client saving for D-Bus•
         * session clients */•
•
        return NULL;•
}•

Now, I think the expectation these days is if an app wants to save state it should do it itself.  But we still need some way to make sure the app gets restarted at login...
So, I should be able to add in the implementation for this function to accomplish that goal without too much effort (the app should already have a keyfile we can look up, and return directly).

I'll look into that on monday. I can also look through the apps we ship by default and see what it would take to set register-session=TRUE for them.  should be a 10 line patch to each app.

So I've done some more investigation into this... There are a number of issues:

1) Gtk exits the application as soon as the session manager enters the END_SESSION phase. In the XSMP days, the applications wouldn't die until the EXIT phase.
Unfortunately, the session gets saved at the end of the END_SESSION phase, so all applications that use Gtk for session registration, will exit before the session
is saved and not get recorded as running in the session.  We could potentially fix gtk to not quit the application in the END_SESSION phase. It already has code to quit the application in the EXIT phase, so the fix would just be code removal i think. or we could change gnome-session to save at the beginning of the end session phase instead of the end of it.  This might have implications for XSMP applications I would need to investigate.

2) in comment 13 I said the expectation these days is if an app wants to save state it should do it itself.  But that's not strictly true. Some state like workspace and window position should be handled by the window manager.  applications shouldn't care about where they are on screen.  The problem is the window manager only can restore the state of XSMP applications, not applications using Gtk's session registration functionality. This is because the window manager only saves the window positions of applications that put the SM_CLIENT_ID property on their client leader window. We could change it to save the position of all windows, but that might break XSMP applications (mutter might match the wrong window up).  Though, we could change it to save the positions of all windows of applications that aren't XSMP managed and just XSMP applications with SM_CLIENT_ID set. Or maybe we should have new dbus api that apps export and mutter uses, saying which windows should be session managed.

3) As a test, I fixed gedit to register with the session manager, and it gets restarted appropriately after my changes to gnome-session to fix the save session but and to add an implementation for dbus_client_save, but it doesn't restore it's open tabs. It used to have code to support restoring its tabs, but that code got dropped when XSMP support was dropped. Likewise nautilus doesn't open up on the same open folders.  So I said in comment 13 that the expectation these days is an app should manage its own state, but the apps don't really do that.

In summary, getting parity with RHEL 6 is tough because: 

- the save button isn't hooked up (small fix)
- the apps don't register with the session manager so the session manager can't know to restart them on login (bunch of small fixes everywhere)
- the apps don't use XSMP anymore and the session manager doesn't have support for restoring apps that use the non-XSMP api (small fix)
- the window manager doesn't know how to restore the window positions and workspaces of non-XSMP apps.
- the apps don't restore their state on their own when started (bunch of big fixes everywhere)
 
I think this outside the scope of RHEL 7 at this point in the cycle. We have a sister bug for this in RHEL 8 (bug 1701156), so let's defer to that.