Sticky windows are no longer usable in the 4.4 series of Xfce. They steal focus on all desktops when changing focus with default Xfwm4 settings. If I activate focus stealing prevention, they no longer steal focus but they get on top in all desktops when focused in the current desktop and after they lose focus on current desktop they remain on top and unfocused on all other desktops. Steps to reproduce this with a sticky xterm window: 1. Open two windows (eg. two Thunar windows) in two workspaces of your choice. 2. Open an xterm window in the first workspace and make it sticky. It is the active window. 3. Make the Thunar window active in the first workspace, the xterm becomes inactive and *below* the new active window. 4. Change to another workspace where you previously had an active Thunar, xterm is inactive but over the active Thunar window (I don't like this either). In that workspace make xterm active and then the Thunar window active sending xterm below the new active window. 5. Change back to the previous workspace, xterm is inactive but *on top* of the active Thunar window. Damn, it was supposed to be below... This was tested with a new user, default settings + focus stealing prevention in Xfce 4.4.0 with Xfwm4 4.4.0 (revision 24671) in X.Org 7.1.1 on Gentoo Linux, the Hardened flavor with default compilation options. As noted above, without focus stealing prevention, the sticky windows also get focused in other desktops when changing their focus in the current one. I've been bitten by problems with sticky windows in Debian Etch (the currently "testing" branch) too since the first 4.4 series that I've tried: Xfwm4 4.3.99.1 (currently at 4.3.99.2). Unfortunately this is getting in the way I've been working in X with various window managers (including Xfwm4 4.2.x) for years, and although I've tried, I cannot live without sticky windows... Thank you.
I have an idea of what's going on here. Both apps use the WM_PROTOCOLS_TAKE_FOCUS which means that the WM send a WM_TAKE_FOCUS client message to the window and the application itself takes focus. When switching quickly between workspaces, there is a race condition between the applications and the sticky one may take focus in place of the right one, thus being focused even when lowered. In xfce 4.2 that did not happen because once a sticky window had focused, it retained focus when switching workspace. IIRC, someone complained about that (like with the desktop remaining focused once the user had switched to an empty workspace where no other wondow could be focused, thus falling back to the desktop) I am not sure there is any simple way to fix this. I've tried with kwin, and I've been able to reproduce the issue with kwin too.
Created attachment 1014 Sort Z-order on workspace change Can you try the attached patch (or resync with current SVN)?
Olivier, thank you for the patch. Unfortunately it doesn't change the behavior of the windows in the above test case. I've also made a screencast (video capture) of the test case with the latest xfwm4 from the 4.4 SVN branch, which seem to include your patch. The video is available at http://dumol.ath.cx/sticky_windows.ogg .
Oh, I see, the ogg file definitely helps understanding the issue.
Created attachment 1015 Raise focused window on workspace switch This patch should fix the issue, and behave just like xfwm 4.2. Can you try it?
Indeed, I cannot reproduce the problem in the above test case anymore with xfwm4 version 4.4.1 (revision 25112). Thanks for the patch and sorry for the delay, I was unfortunately unavailable for the weekend. I guess it's time for a FIXED resolution. I'm trying this new version in my day-to-day user account to see if I the focus issues with sticky windows go away in normal usage. And if they do, I'll come back to close the bug. Thank you once more.
You're welcome. Changing status to fix then.
After 10 days of using the fixed version 4.4.1 (revision 25112) in my day-to-day account I must admit the situation is considerably ameliorated but unfortunately not completely fixed. I cannot reproduce the initial test case illustrated in the above screencast. In fact, I have no more issues when only two workspaces are involved. However, if I switch between three or more workspaces and the sticky windows has different focus states in them, in the end the sticky window will get on-top on all three or more workspaces. I've made a second screencast to illustrate this new issue and uploaded it to http://dumol.ath.cx/sticky_windows_reloaded.ogg . The sticky xterm windows will change focus in workspace 2, but only when I change workspaces at least twice before returning to workspace 2 (it keeps the unfocused state in workspace 2 when I only change to workspace 3, but gets on-top when I change to workspace 4 before returning to 2). Thanks for all the attention, the second patch has made my life considerable easier in Xfce 4.4.
Created attachment 1033 Fix "is-top-most" computation Yes, it's just the test to see if client is top most that introduces that bug. The following patch fix that (committed in both trunk and xfce_4_4 branch) Also, please note that the option "raise on focus" might change the behavior, since the window will be raised when focused if the option is enabled (ie, keep it disabled in your case)
Indeed, I have installed xfwm4 version 4.4.1 (revision 25175) and I cannot reproduce the behaviour from the second screencast. Sorry for reopening, I'm changing to FIXED again and will come back to close it for good after a few days of daily usage if everything seems fine in relation to the focus of sticky windows. Mighty thanks... An unrelated observation: at least the last two SVN revisions that I've tested in the last weeks (25175 and 25112) seem to have a problem with the shortcuts for changing current workspace. E.g. I'm in workspace 1 and pres Alt-F2 to get to workspace 2, but if I press Alt-F2 again in workspace 2, I get to the last current workspace, in our case workspace 1.
(In reply to comment #10) > An unrelated observation: at least the last two SVN revisions that I've tested > in the last weeks (25175 and 25112) seem to have a problem with the shortcuts > for changing current workspace. E.g. I'm in workspace 1 and pres Alt-F2 to get > to workspace 2, but if I press Alt-F2 again in workspace 2, I get to the last > current workspace, in our case workspace 1. This a feature, not a bug (not even a new one actually). It allows the user to switch back and forth between two workspaces using the same shortcut. To disable this feature, open the WM Tweaks settings, select the "Workspaces" tab and uncheck "Remember and recall previous workspace when switching via keyboard shortcuts"
(In reply to comment #11) > > To disable this feature, open the WM Tweaks settings, select the "Workspaces" > tab and uncheck "Remember and recall previous workspace when switching via > keyboard shortcuts" Ouch, my bad... Indeed, it's a feature/tweak. I've disabled it now, it doesn't make much sense to me and made me confused more than once, because sometimes I'm trying to switch to a certain workspace without realizing I'm there already and the result was unexpected (it changed to the previously visited workspace). Might I suggest this preference to be disabled by default? Sorry for talking about an off-topic problem here, won't do it again.
Xfwm4 version 4.4.1 (revision 25175) contains the third patch which fixes the problem completely. Many thanks!