After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591642 - metacity doesn't shutdown propertly anymore when doing --replace
metacity doesn't shutdown propertly anymore when doing --replace
Status: RESOLVED DUPLICATE of bug 588119
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2009-08-13 01:43 UTC by Ray Strode [halfline]
Modified: 2009-08-13 02:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2009-08-13 01:43:27 UTC
When a window manager does --replace to replace a running metacity instance, that instance doesn't shutdown properly.

It's supposed to set its restart hint to SmRestartIfRunning so the session manager doesn't immediately try to restart it when it exits.

It used to do this, but looks like it got broken by this commit:

http://git.gnome.org/cgit/metacity/commit/?id=abbd057eb967e6ab462ffe305f41b2b04d417b25

process_selection_clear sets the_display to NULL so meta_session_shutdown aborts early.

Note the session manager talks over libICE not through the X server so you don't need a display to talk to the session manager.

I don't think it makes sense to call

warn_about_lame_clients_and_finish_interact 

from meta_session_shutdown either.  On shutdown the session manager treats the window manager special.  After all other apps have chimed in, the session managers asks for phase 2 of the shutdown process, when put in that phase, it will do an interaction request.  if the session manager grants that request, then 

interact_callback

will get called which calls

warn_about_lame_clients_and_finish_interact 

while there is still a display active.

Note, we'd never want to call that function when being --replaced.  

I think I'd recommend reverting the commit entirely. Did it solve a specific problem?
Comment 1 Ray Strode [halfline] 2009-08-13 02:12:24 UTC

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