GNOME Bugzilla – Bug 658121
ATs cannot consume all keystrokes
Last modified: 2021-07-05 10:45:02 UTC
Created attachment 195570 [details] test script Steps to reproduce: 0. Be sure gedit is NOT running. 1. Start two *inaccessible* terminal applications (e.g. use xterm. do NOT use gnome-terminal). 2. In the first xterm, launch the attached test script. 3. In the second xterm, launch gedit and begin typing in it. Expected results: All key events get consumed other than letters. Actual results: Locking keys (like Caps_Lock) are also failing to be consumed. I'm not sure if this is indeed an AT-SPI2 bug, but this bug did not used to occur, and Orca users of the laptop layout have been complaining about the state of Caps_Lock being toggled unexpectedly. So I'm starting here.
AT-SPI and ATK are passing on to gtk that the key should be consumed, even for caps-lock, but somehow that isn't preventing the state from being changed anymore.
Any ideas as to where this problem needs to be fixed?
My guess is that this has never really worked right at the ATK/AT-SPI level (ie, AT-SPI will notify ATK (and, thus, GTK+) that the key should be consumed, but the lock gets toggled anyway). There is code in orca and the shell script to invoke xmodmap, and this is intended to prevent the locking behavior of the caps lock key, but now this seems not to work anymore, for some reason, and I haven't figured out why exactly (maybe someone who is very familiar with xmodmap would have no trouble figuring it out).
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
*** Bug 669213 has been marked as a duplicate of this bug. ***
I'd really like to remove Orca's xmodmap-related code. That code has always been nothing more than a collection of really sad hacks. And I've just discovered that certain hardware events can stomp on those hacks (e.g. connecting my Plantronics USB headset adapter is resulting in the locking behavior of CapsLock being restored). So it looks like I need to add yet another sad hack onto the pile. :( Or we could figure out how to cause locking keys to be consumed, and I could make Orca more reliable by deleting a bunch of code. :)
Moving open tickets in at-spi2' "registry" Bugzilla component to "at-spi2-core" as it has a subdir called "registryd".
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/ Thank you for your understanding and your help.