GNOME Bugzilla – Bug 712595
inconsistent state (undecorated windows, no app menu) during shutdown
Last modified: 2021-06-14 18:21:40 UTC
When I shutdown my system, app menus briefly appear inside any visible windows. It looks broken.
<aday> mclasen - i've seen the app menu appear inside gtk windows as i've shut down. is that a gtk or a shell issue, do you think? ... <mclasen> aday: sounds like gsd going away too early, causing gtk to think that the desktop shell doesn't show app menus ... <aday> mclasen, i also see the system-shutdown icon appear in the top bar. could that be the same bug? <mclasen> aday: could well be
It stops when it's told to by gnome-session, we don't control that one bit.
This type of bug goes back a long way - there's also a variant where we kill the window manager, so you briefly see undecorated windows. The way this works is that gnome-session tells explicitly registered clients to exit. I think there are two possible fixes here: 1) gnome-shell and gnome-settings-daemon could just ignore this 2) We stop sending the Stop request to just those components specifically Really, these session programs should just be scoped to the X server - they should die only when *it* is dead and we're starting a VT switch to gdm (or plymouth in the case of shutdown).
just remember that the login screen's g-s-d and gnome-shell need to be killed before the user's session is started even though the X server doesn't die in between. I agree they shouldn't get killed until the end though. IIRC, i think we already did this for gnome-shell.
(In reply to comment #4) > just remember that the login screen's g-s-d and gnome-shell need to be killed > before the user's session is started even though the X server doesn't die in > between. Er, right I keep forgetting about the "special" case of login-retaining-X-server. But for login you do kill the session bus right? And both g-s-d/gnome-shell should be scoped to the session bus as well. However the truly ugly thing is that on login we'd need to wait for them to exit synchronously - otherwise we'd have a race condition where the old gnome shell could still be running while the new one is starting and trying to grab the compositor atom.
I think I was wrong in my analysis, actually - gsd going away should lead to any client-visible xsettings changes per se. What probably happens is that gnome-shell disappears off the bus, and the xsettings plugin picks that up as a hint that the shell-shows-app-menu setting nees to be toggled.
*** Bug 691425 has been marked as a duplicate of this bug. ***
The change in appearance is not only about app menus: I also see the theme and toolbar look change. So it may well be that gsd is killed too early.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.