Steps to reproduce: 1. Set Super to the window drag modifier (Key used to grab and move windows). 2. Set Next workspace to <Super>Left. 3. Hold down Super and press left more than once. The first time you press it everything works. Sometimes even the second and third time. Eventually xfwm4 (I think) forgets you're holding down Super for the sake of the keyboard command but still thinks it's being held down for the sake of moving windows. Focus will change but no keyboard commands will work. To get out of this broken state you have to drag a window a few pixels and then xfwm4 realizes Super isn't being held down anymore. From there clicking works as if Super wasn't held down and <Super>Left works again. If you let go of Super every time you change workspaces (ie. <Super>Left, <Super>Left, <Super>Left) instead of holding it down (<Super>Left Left Left) xfwm4 will never get confused. I haven't tried this with other drag modifiers (Alt) but it's possible it works the same way. I also have focus follows mouse on but I don't think that has anything to do with it.
Test in xev, I suspect that your Super key is seen both as a modifier and a regular key. 1. Run xev 2. Move the pointer to the window 3. Press the Super key Do you see the events repeating after a little while? (I do here) In that case, there is nothing I can do, use another modifier and close that bug as invalid.
BTW, I don't see that happening here. Please provide the output of "xfwm4 --version"
I've now been able to reproduce it.
Can you try with svn trunk revision 29516 or later?
Yes, the Super_L event does repeat. The output of xfwm4 --version: This is xfwm4 version 4.5.99.1 (revision 29379) for Xfce 4.5.99.1 Released under the terms of the GNU General Public License. Compiled against GTK+-2.14.7, using GTK+-2.14.7. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Embedded compositor: Yes - KDE systray proxy (deprecated): No Can I just build xfwm4's svn version and leave all the other components at RC1? Or do I need to rebuild everything?
(In reply to comment #5) > Can I just build xfwm4's svn version and leave all the other components at RC1? > Or do I need to rebuild everything? Good point, there's been a API change in libxfcegui4 since RC1. So it'd much easier for you to just pick that specific change and apply it to the xfwm4 sources from RC1: http://svn.xfce.org/index.cgi/xfce/xfwm4/trunk/src/events.c?r1=29516&r2=29515&pathrev=29516
After preliminary testing this patch seems to fix the problem. I'll continue running with it for a while and see if it comes up again. Thanks!
I just had it happen once. It's possible that it's happening quite a bit less often now though.
Adding blocker as current svn status is badly broken and leads to lockups of the WM
I think I've had the same problem, weirdly it only started appearing when I switch from the xorg kbd/mouse drivers to the evdev driver. But I suppose it's possible I updated xfwm4 at the same time, or maybe just evdev makes the problem more apparent. But mine is a little different. I have <Alt><Shift>Left/Right/Up/Down set for changing workspaces. Pretty often something weird happens and I lose all keyboard control after changing workspaces. Grabbing and dragging a window fixes the problem. Is this the same thing, or something else?
(In reply to comment #10) > Is this the same thing, or something else? Possibly the same. For now, please test as much as you can current svn code. I just committed yet another change (rev. 29524.)
Jason, can you try the current code? In doubt, just grab the source "events.c" from http://svn.xfce.org/svn/xfce/xfwm4/trunk/src/events.c and rebuild.
(In reply to comment #12) > Jason, can you try the current code? In doubt, just grab the source "events.c" > from http://svn.xfce.org/svn/xfce/xfwm4/trunk/src/events.c and rebuild. Well, sorry, not quite so, just copy/paste the handleKeyPress() function.
Ok, with current svn trunk, I can't reproduce the problem anymore... my problem, at least! Yay, one annoyance gone.
Yes, I cannot reproduce the problem reported anymore with current svn code either. But it's a race condition so it can be tricky to make sure it's gone entirely. I'd like to have Jason, who reported the issue at first, to confirm this too before closing.
I'm testing it now. I don't expect to spend enough time on it till tomorrow at least.
Created attachment 2184 Backport of the changes to RC1 (In reply to comment #16) > I'm testing it now. I don't expect to spend enough time on it till tomorrow at > least. Ok, I am attaching the backport of the changes to RC1, so we are sure that all changes are included in your test. Simply replace the source src/events.c in your build with this one and rebuild xfwm4 before testing.
With this bug being gone for 2 out of 3 testers, with no mention of this still being present. Can we assume it's gone? :-)
Sorry, lets wait for Jason to report back. (hopefully with some good news)
So far I haven't had that exact problem. Once I had super+tab (switch windows) break on me in a similar way, except I couldn't drag any windows. I actually had to start a different program from the console to get control back. Other than that, things look good.
Ok, removing the blocking flag then.
(In reply to comment #20) > So far I haven't had that exact problem. Once I had super+tab (switch windows) > break on me in a similar way, except I couldn't drag any windows. I actually > had to start a different program from the console to get control back. Cycling has an active grab on the keyboard and pointer, so it's a different code path. The only cause I can see for this would be if the timestamp used to release the active grab is inaccurate, so to be safe I've now changed the code a bit to use the special timestamp CurrentTime. It's in revision 29550.
Yeah, I've noticed the grab not dropping after a cycle windows on occasion, usually just when the machine is under load... a timestamp issue seems to fit that.
Cannot reproduce anymore, closing.