User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060414 Firefox/1.5.0.2 Build Identifier: 4.3.90.1 When hitting alt-tab to cycle through windows in xfwm4 4.3.90.1, i get the window list panel as usual and can tab through it, but when i release the alt/meta key, the panel stays up and will not exit. I can continue to hit tab or shift-tab to cycle windows (with or without alt/meta depressed) but i cannot make the panel exit and actually give focus to the selected window. I have not found any way to make it disappear short of killing xfwm4. This effectively locks the WM. Reproducible: Always Steps to Reproduce: 1. In xfwm4, hit alt-tab. 2. Release alt. Actual Results: Alt-tab windows cycling panel does not exit, WM stays locked in windows cycling behaviour and is unusable for anything else. Expected Results: Panel should disappear and selected window should get focus. I'm running a custom-compiled version of xfwm4. Configure was run with --enable-compositor though i don't actually have the Composite option turned on in the X server. I also had CFLAGS set to -DSHOW_POSITION while building. The system is an entirely homebrew from-source linux install, but this behaviour doesn't seem too likely to be related to that. Still, it's possible some non-standard option somewhere is interfering... Please let me know if there's anything else i can provide to help tracking this down.
What if you simply press and release the alt key again?
Oops - sorry, i meant to make that clear: no, it doesn't help. I've tried any number of key-mashings and mouse-clickings to no avail, including simply hitting and releasing either/both alt keys again. I've seen cases before where a shift-state gets stuck and that works, but not in this case.
Can you try this xev | grep keysym Move the pointer within the xev window and press Alt, then report the lines given.
Can you try with revision 21216, snapshot available here: http://www.xfce.org/~olivier/preview/xfwm4-4.3.90.2-r21216.tar.bz2
Found the problem! It's some odd modmapping on my end, though this may still be something you want to address; i've not experienced any similar problems before with alt/meta either in previous versions of xfwm4, in other window managers (WindowMaker has a similar windows cycling panel), or in other programs. I checked my various Xmodmap files, and the only thing i can find related to alt/meta keys was the following, which my comment indicates i added years ago to fix some problem with remote VNC sessions, where the alt keys weren't working as meta keys at all: keysym Alt_L = Meta_L Alt_L keysym Alt_R = Meta_R Alt_R I commented that out and restarted the xserver, and voila, alt-tab cycling now works in xfwm4. Sorry for the false alarm but like i said, the report may still be helpful. In case it helps, here was the relevant output from xev before i made the change: state 0x0, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES, and after: state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, I will also try the SVN snapshot you linked and see if that works with the crazy modmapping - will let you know. Though i think i'll just remove those lines permanently anyway, unless the VNC problem crops up again...
Hi again - the SVN snapshot didn't change anything. Anyway, i've solved the problem for myself (until next time i use VNC, perhaps!) but it still may be worth tweaking the behaviour. Again, alt(meta)-tab worked fine under xfwm4 4.2 even with the funky modmapping.
Humm, not surprising then, you change the mapping of Alt to Meta. xfwm4 is waiting for Alt, so that's "normal" that it loops until it gets its key release event on Alt. Alt+Tab won't work in VNC from Windows anyway since Alt+Tab is used by windows itself. Until Xfce 4.4, it was possible to change the modifier to use something else than Alt but this is useless IMHO and is removed in 4.4.
Hi - but if it won't accept the meta-mapped key *release*, why does it accept the meta keypress in the first place? Better behaviour would be to ignore the keystroke from the start, if you will only accept alt and not meta - otherwise, as we've seen, you lock the user out from using the WM altogether. And meta and alt are often mapped to the same key in my experience... The VNC issue wasn't specifically for using alt-tab, but for other alt (meta) combinations, which didn't work (from another linux box running debian, actually, according to my notes). It would be nice to make the keystroke / modifier customisable. For example, on my work box using windowmaker, i map all the key combinations that normally use the alt/meta key to use the `windows' key on the keyboard instead - that way i can direct my keypresses either to the local WM or to the one running in VNC just by switching modifiers - works really nicely. I know it used to be mappable in xfwm4 - in fact, a `cycle_windows_key' shortcut still shows up in the WM preferences -> keyboard dialogue still (maybe left over from my 4.2 install?), but changing it doesn't change the actual keystroke used. I'd vote for making it customisable again - it can be very handy in situations like i described before, and when all the other keys are customisable, why prevent users from customising that one? It seems quite inconsistent.
Humm, no, it's not useful to make that specific key combination customizable as less than 0.01% of users would make use of that anyway. BTW, the code should work even with broken keymap (checking for any modifier release but shift that has a special meaning), so I'm resolving that bug.