Hey, a debian user reported a bug against xfwm which I'm not really able to handle. This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567607 and there's a test case added. I can't decide on the validity, so I'm letting you know and will forward the user here so he can explain what he thinks.
Hi, I'm the one who reported this to Debian originally. Some additional info: This is a regression from 4.4.2-5. In that version, window-state-event is sent correctly when changing the sticky state: $ ./stick >>> Right-click title bar, click "Stick". Sticky? Yes. >>> Right-click title bar, click "Unstick". Sticky? No. Compare this to the behavior of 4.6.1-1: $ ./stick <<< Right-click title bar, click "Always on Visible Workspace" Sticky? Yes. Sticky? No. <<< Right-click title bar, click "Only on This Workspace" Sticky? Yes. Sticky? No. This bug is affecting Audacious media player, and there I've had to disable tracking the window-state-event because every current window manager I've tried sends it wrongly in one way or another. Back in October I had added the event tracking, so I guess it must have worked correctly with whatever version of XFWM I was using at the time, but since then a user reported that it was broken with OpenBox, and while trying to reproduce I found that it was now broken with XFWM. http://jira.atheme.org/browse/AUD-73 http://jira.atheme.org/browse/AUDPLUG-178
I would have to check how gtk reports the "window-state-event" changes, because _NET_WM_STATE(ATOM) rightfully set/unset _NET_WM_STATE_STICKY.
That's a clear bug in gtk/gdk, the value reported changes every time the window manager updates _NET_WM_STATE Try by yourself, run metacity (if you don't trust me) and stick the test window. Now maximize, see how the sticky is reported as "no" whereas the window is clearly still sticky. Other tests confirm this behavior. What you see in xfwm4 is the result of two consecutive udaptes to _NET_WM_STATE (this can and will be fixed, however the real bug is in gdk and it remains).
Another problem in gdk is that the value read for workspaces when sticky is 0xFFFFFFFFFFFFFFFF and this is compared to 0xFFFFFFFF (play with gdb and break on gdk_check_wm_desktop_changed() in gdk/x11/gdkevents_x11.c) As a result, toplevel->on_all_desktops is *never* true, that goes on top of the other bug with consecutive updates of _NET_WM_DESKTOP Seems to me gdk is pretty buggy here.
Bugs are in gdk, not in xfwm4 -> invalid