GNOME Bugzilla – Bug 115384
Capslock makes keyboard shortcuts work incorrectly
Last modified: 2004-12-22 21:47:04 UTC
I pressed ^t and waited for new tab to open. Instead Ephy did hide my location bar. "Wtf?" I asked. I had accidentally pressed capslock. So, capslock should not have effect on keyboard shortcuts. It works correctly on other GNOME apps, like Evolution.
Gtk2 evolution you mean ?
evolution-1.4.0-2 I mean. Works atleast in Evolution, Pan, gnome desktop switcher, gnome-calculator and so on. It also works in Ephy's menu's... (Try capslock and ^w) Something weird with ^t and ^T...
I have sneaking suspicion this has something to do with gtk+ since ctrl+N works with or without capslock but ctrl+T acts like ctrl+shift+T with caplock.
Strange, this works correctly for me. I'm using Debian unstable and newest epiphany from CVS. GTK+'s version is 2.2.1 and mozilla's 1.3.1.
Could be a gtk regression, I posted a similar bug about keys some days ago (ctrl/alt F1 open help).
1.0 if we can fix it.
Could be 100439
Reproducable with gnome terminal (caps lock + ctrl t opens a new tab).
Mostly fixed in CVS. Tue Aug 12 14:27:42 2003 Owen Taylor <otaylor@redhat.com> * gtk/gtkkeyhash.c (_gtk_key_hash_lookup): Remove GDK_LOCK_MASK before calling gdk_keymap_translate_keyboard_state so bindings and accelerators are independent of the Caps-lock key. (#115384, reported by Toni Willberg) Two minor issues remain: - The same thing should probably apply to NumLock as well as CapsLock, though I'm not entirely sure about that. - For certain keyboard setups (XFree86 with the caps:shift option, in particular), the modifier for the caps-lock key is not GDK_LOCK_MASK, but something else. In order to handle such cases we need to search for the appropriate modifier rather than assuming it is GDK_LOCK_MASK. The best way to handle these things is probably to have something like a alternative version of gdk_keymap_translate_keyboard_state() with a flags field that can be set to include GDK_TRANSLATE_NO_LOCK_MODIFIERS flag.
Ivan Pascal points out that the way caps:shift is implemented, it actually will work. (Some magic is done so that Lock is not in the consumed modifers for normal operation, but is in consumed modifiers for caps:shift - this is why we have the '& ~tmp_modifiers' in: if (state & ~tmp_modifiers & LockMask) tmp_keyval = gdk_keyval_to_upper (tmp_keyval) in gdk_keymap_translate_keyboard_state(). Closing, because I suspect that stripping out NumLock probably is not a good idea.