GNOME Bugzilla – Bug 607117
fetch_net_wm_check_window uses timer to cache negative result when it should instead be event-driven
Last modified: 2018-02-10 03:42:03 UTC
GTK wm property functions call fetch_net_wm_check_window() to see whether the window manager supports the _NET properties. This function caches its result for 15 seconds. This means that if the function is called before the window manager manages to establish the "I support this" property, for example if a GTK app is started simultaneously with the window manager and races at startup, GTK will cache that the WM doesn't support these properties for 15 seconds. Instead, GTK should monitor property changes on the root window for changes to the _NET_SUPPORTING_WM_CHECK property. It appears that GTK already tracks when the window manager changed: http://developer.gimp.org/api/2.0/gdk/gdk-X-Window-System-Interaction.html#gdk-x11-screen-supports-net-wm-hint and in fact, the docs there tell you not to cache the results; so it seems could use that event to know when to reset its cache, rather than the 15 second timer. As it stands, even if an app properly monitors the window_manager_changed signal, functions like gdk_x11_screen_get_window_manager_name will return the wrong result when the cache is wrong.
We intentionally do not select for property notify on the root window. You really don't want every single app on your desktop to wake up everytime any property on the root window changes. I have at some point proposed to add the ability to monitor individual properties to the XFixes extension. If that ever happens, we can start monitoring the property.
Would the ClientMessage events that window managers send to the root window after taking ownership of WM_Sx selections (per http://tronche.com/gui/x/icccm/sec-2.html#s-2.8 ) work as a trigger for resetting the cache?
Sure, that should work. Some care is needed to avoid emitting window-manager-changed twice for every wm change, since we already watch for the previous wmspec-check window to go away and emit the signal in response to that. A patch would be welcome.
(In reply to comment #2) > Would the ClientMessage events that window managers send to the root window > after taking ownership of WM_Sx selections (per > http://tronche.com/gui/x/icccm/sec-2.html#s-2.8 ) work as a trigger for > resetting the cache? Using the ICCCM ClientMessage for the WM selection is still racy. For instance, mutter/metacity only set _NET_SUPPORTING_WM_CHECK on the root window after sending the ClientMessage so there's a race window there. It could be argued that that is a bug in mutter/metacity but it's not clear that the order can be easily changed nor did I find in the EWMH spec any request about the order in which WMs should send the manager selection ClientMessage and set _NET_SUPPORTING_WM_CHECK. So, it seems that the only option here to make this race free and totally event driven is to watch the root window for property changes. But, as Matthias says, that has to wait for an XFixes extension. What we could do for now is remove the 15s timer and always do the round trips when not running a _NET_SUPPORTING_WM_CHECK compliant WM. The patch in bug 666921 already doesn't rely on this timer for compliant WMs.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.