! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
sticky state reported wrongly


Description Yves-Alexis Perez editbugs 2010-01-30 09:43:40 CET

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.
Comment 1 John Lindgren editbugs 2010-01-30 13:40:23 CET
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.

Comment 2 Olivier Fourdan editbugs 2010-02-01 09:11:55 CET
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.
Comment 3 Olivier Fourdan editbugs 2010-02-23 15:38:05 CET
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).
Comment 4 Olivier Fourdan editbugs 2010-02-23 15:41:41 CET
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.
Comment 5 Olivier Fourdan editbugs 2010-02-23 15:44:00 CET
Bugs are in gdk, not in xfwm4 -> invalid

Bug #6192

Reported by:
Yves-Alexis Perez
Reported on: 2010-01-30
Last modified on: 2010-02-23


Olivier Fourdan
CC List:
1 user



Additional information