Red Hat Bugzilla – Bug 122752
Alt-Tab doesn't terminate
Last modified: 2007-11-30 17:10:42 EST
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,
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
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?
*** 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
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:
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