With FC2 devel as of Friday: Do an Alt-Tab: the selector window pops up normally, and I can bounce between selections as I always have, with highlight rectangles showing the selcted window. Release the keys: nothing happens. The selector window and highlight stay on the screen, and I have to click the mouse to get the desktop back into "normal" mode. My selected window doesn't get the focus, either.
With FC2 test3 I get the same behavior. The selector window pops up, alt-tab cycles between selections with highlight rects appearing, but there doesn't seem to be any way to make the selector change the top window. It's as if it can't "hear" the keyup event for the alt key. (On my machine the selector window keeps responding to tab presses even after you release the alt key.)
On my system I am having no problems what so ever with alt + tabing between applications. I am running an yum update now, will let you know if any thing changes.
On Fedora Core 2 final I still get this behavior.
What's the proper route to changing this bug's scope to Fedora Core 2 final instead of test 3, btw?
Changing version.
*** Bug 123792 has been marked as a duplicate of this bug. ***
I can duplicate as well--but only when using the right alt key instead of the left one.
This also affects Ctrl-Alt-Arrow, and again, it is only a problem when the right alt key is used instead of the left.
Interesting! Just tried that on my machine and sure enough left-tab-alt does terminate. Does this mean there's something odd about the keymap perhaps?
Happens to me, too, but only with with Windows keys. Seems reproducible on the three different platforms I have. Some details: 1. When using the Keyboard Shortcuts capplet to configure shortcut keys, depressing the <WIN> key stop the key combination process. 2. Whereas in my older system, the symbold <Mod4> would be used for the WIN key, now it seems to use <Super_L> 3. Manually gconfiguring /apps/metacity/global_keybindings/cycle_windows to "<Mod4>Tab" would allow me to WIN-Tab cycle through the various windows, but it seems the key gets "stuck". Releasing they keys would leave metacity in windows cycling mode.
I filed upstream with the extra information I've found at http://bugzilla.gnome.org/show_bug.cgi?id=142947
As noted upstream, this isn't a Metacity bug. A simple "xmodmap | grep mod1" on FC2 shows mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) Alt_R is clearly missing from the list, but a simple xmodmap -e "add mod1 = Alt_R" will fix that and get rid of this "remaining-popup" problem, at least until the Xserver restarts (i.e. until you log out). This should be reassigned against the X packages. [Also, note that this is specific to FC2, as Alt_R does appear in the list for me in FC1]
I came by to check on the status of this bug, as it has been silent and unfixed for the past week or so. It turned out to have been assigned to "xfce-utils", which has to have been a mistake. I assume xorg-x11 is the appropriate component?
Yeah, xorg-x11 seems right to me. Since I'm not privileged, could someone also change the summary to "Alt_R doesn't appear in mod1 list from xmodmap, causing various Metacity issues" or something similar?
I just wanted to add that adding the entries via xmodmap solved the problem for Alt_R and Super_R but not for Super_L (which actually appears in the xmodmap default to begin with).
Temporary fix for Super_L problem: $ xmodmap -e "clear mod4" $ xmodmap -e "add mod4 = Super_L" Doing an xmodmap after this will show that two values have been assigned to Super_L: mod4 Super_L (0x73), Super_L (0x7f)
Note: This may also be an issue of control-center's (specifically gnome-keyboard-properties). I tried creating an $HOME/.xmodmaprc file and was informed that gnome-keyboard-properties handles it now. However, after trying the various combinations in gnome-keyboard-properties, none of them fixed the mapping for either Alt_R, Super_R or Super_L.
The X.org 6.7 release included an update (XFree86 4.4 seems to have it too) to the xkb files which changes the way Alt_R is setup. I've filed a bug in the X.org bugzilla: http://freedesktop.org/bugzilla/show_bug.cgi?id=926
In that freedesktop.org bug, they claim they won't revert the Xorg/XFree86 change and that Metacity has to be modified. Could this bug be reassigned back to Metacity? Of course, Havoc might mark this as upstream; the same issue is now being covered at http://bugzilla.gnome.org/show_bug.cgi?id=151554 .
Soeren submitted a patch against metacity upstream at the URL in my last comment which fixes this issue.
Soeren put the fix in our package and I rebuilt it, should be in rawhide soon.