Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=471927
Bug Zapper fedora-triage-list@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|rawhide |10
--- Comment #10 from Bug Zapper fedora-triage-list@redhat.com 2008-11-26 00:31:26 EDT ---
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'.
More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Comment #11 from Akira TAGOH tagoh@redhat.com 2008-11-27 01:31:42 EDT --- I got a trick. the scenario is:
1. metacity runs on gdm. and metacity is set an own window id to _NET_SUPPORTING_WM_CHECK. 2. the desktop session is going to start without restarting X server. and metacity is gone. but _NET_SUPPORTING_WM_CHECK is still there, with invalid window id. 3. imsettings-xim is running. it grabs same window id. thus, window id on _NET_SUPPORTING_WM_CHECK is valid again. which isn't right. 4. xfce-mcs-manager is running before xfwm4. and the unexpected window id is set to GDK_SCREEN_X11 (screen)->wmspec_check_window. it's cached during the instance is alive. so gdk_x11_screen_get_window_manager_name() always returns the unexpected name.
There are some points:
a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it may be dangerous since the window id could be reused. b. invoking xfce-mcs-manager before xfwm4 may be not a good idea as long as it uses gdk_x11_screen_get_window_manager_name(), because of caching the value. it's still likely to return "unknown" if no _NET_SUPPORTING_WM_CHECK is set to the root window and it's being cached before running xfwm4. c. or using gdk_x11_screen_get_window_manager_name() in xfce-mcs-manager may be not a good idea. d. or caching the value in GdkScreen may be not a good idea.