GNOME Bugzilla – Bug 434948
[pending] KP_Insert+Shift cannot be used as modifiers in an entry
Last modified: 2007-05-07 15:52:56 UTC
Holding down Shift while typing keys on the keypad causes the keypad to function as if NumLock were on. This interferes with the use of KP_Insert+Shift for Orca keystrokes (such as Insert+Shift+Tab to go to the previous form field in Firefox). Steps to reproduce: 1. Navigate to an entry 2. Hold down KP_Insert and Shift Expected results: 0s would not be typed into the entry Actual results: 0s are typed into the entry
The offending code here seems to be in orca.py._processKeyboardEvent. The problem is that it is comparing the event_string of the keyboard event to determine if the key pressed is the Orca modifier key or not. Thus, when faced with differing keysyms from the same key (e.g., KP_Insert, and KP_0), the match fails. A potential solution to this problem would be to compare the hardware keycode of the key event with the set of keycodes associated with the Orca modifier keys. The potential odd case we need to consider, however, is that of some operating systems that choose to modify the keycode for a key based upon things such as the NumLock modifier. I recall running into such a case on a particular operating system shipped by a company I know well.
Created attachment 87345 [details] [review] Patch to compare keycodes instead of keysyms when determining Orca modifier This patch compares the keycodes instead of the keysyms when looking for the Orca modifier. It also "unprivatizes" keybindings.getKeycode (i.e., renamed to getKeycode from _getKeycode), which resulted in changes in the J2SE-access-bridge module. J2SE-access-bridge was using the private form, and that's really the only logical stuff I changed in that file. But, untabifying the file and deleting trailing whitespace made things look a lot worse.
I got this error when I tried the patch: Traceback (most recent call last):
+ Trace 131738
consumed = self.callback(event)
orcaModifierKeycodes.append(keybindings._getKeycode(keysym))
Created attachment 87346 [details] [review] Take 2 D'Oh. Somehow, the _ squeaked in. It's now out.
This seems to work. No more 0s with form field navigation. Thanks!!
I had a concern that Solaris might cause us grief with hardware keycodes for the keypad, but that doesn't seem to be a problem after testing with it today. Committed the patch and marking this as pending.
Will, this patch seems to be responsible for bug #435338.
(In reply to comment #7) > Will, this patch seems to be responsible for bug #435338. > Dang. I'll take a look. Can you also please try to revert just the J2SE*.py file, with the exception of just this portion: - keyboardEvent.hw_code = keybindings._getKeycode(keysym) + keyboardEvent.hw_code = keybindings.getKeycode(keysym) In addition, do you notice any stack traces?
Created attachment 87444 [details] [review] Patch to accommodate Java keycode oddness The problem is that the Java access bridge chooses to emit Java platform keycodes instead of the keycodes of the base platform. This patch has us check for either the keysym or the keycode, which should get us a match. I'm a little nervous about it, though, since we are in the unlucky situation of having an overlap between Java keycodes and base platform keycodes. As a result, we might run into a situation of false positives. I'll need to take a look at the overlap and see what problem keys exist.
Reverting just the J2SE*.py bit with the exception of the line you mention didn't make a difference. As for stack traces, I got some COMM_FAILURES. Did some quick testing of your new patch (form field navigation and the download manager) and this seems to solve the problem. Thanks!
Created attachment 87455 [details] [review] Alternative patch This is an alternative to the previous patch. It eliminates the risk of False positives due to overlapping keycodes between what we get from the Java access bridge and what we get from the base platform. What it does is determine all possible keysyms bound to the keys associated with the Orca modifier key. If a keyboard event string matches any of those, we call it the Orca modifier. There is still a risk, however, that more than one key might have the same Orca modifier keysyms associated with it. For example, assume some adamant person running out of reasons to bang on a table decided they wanted Shift+w to produce KP_0 just for the sake of being able to complain about something. In this case, I believe we'd get a match -- the KP_Insert key is capable of producing KP_Insert and KP_0. With the keyboard map change from our user, the w key is capable of producing w and KP_0. Who would ever want to type a capital W is beyond me. I believe with this patch, a key event string matching any keysyms associated with the keys that produce the Orca modifer would count as the Orca modifier. So, Shift+w would produce KP_0 and cause a match. This specific example is of course unlikely. If we cannot think of more likely cases, however, I think we might want to consider this patch instead of the previous one.
With this patch, holding down just KP_Insert and Shift gives me 0s in an entry.
(In reply to comment #12) > With this patch, holding down just KP_Insert and Shift gives me 0s in an entry. > Argh. That's because we're getting '0' and not 'KP_0' as an event_string. That blows chunks. This is getting far more complicated, as what often happens when we try to work around other people's bugs. :-( When I look back at the keycode way of doing things, I notice this with the Java/X11 keycode overlap problem: Keycode 90 on X11 for Linux: KP_Insert Keycode 90 for Java: Z Keycode 66 on X11 for Linux: Caps Lock Keycode 66 for Java: B If I'm thinking straight, if someone were to press Z when in Java, it would emit a keycode of 90. This, in turn, would match the X11 keycode of KP_Insert, telling us it was the Orca modifier (same thing for 'B' if the user were using the Caps Lock modifer). Yech. Who needs Z and B keys, anyway? OK...I'm going to give this a rest. The solution is probably easy and I'm just too deep in it to see the forest.
Created attachment 87542 [details] [review] Modified alternative patch This patch is a variant on the previous patch and does a bit more monkeying around with the keymap. Seems to work better, though I really don't like modifying the keymap. Unfortunately, I cannot think of a better way to work around the bug in the Java Access Bridge right now.
Comment on attachment 87444 [details] [review] Patch to accommodate Java keycode oddness I'm going to reject this one because the keycode overlap between Java and X on Linux is not good: Keycode 90 on X11 for Linux: KP_Insert Keycode 90 for Java: Z Keycode 66 on X11 for Linux: Caps Lock Keycode 66 for Java: B
Latest patch works for me.
Patch committed. Marking this as pending. I've tested it with the Java platform, GNOME apps, and with both the Desktop and Laptop keybindings. It seems to do OK.
I've just tested this with form field navigation in firefox and it seems to be working fine. I did not notice any zeros or anything and the command was working fine.
Closing as FIXED.