GNOME Bugzilla – Bug 671976
Orca commands are sometimes passed through to the application
Last modified: 2021-07-05 10:45:41 UTC
Recent improvements to at-spi2-core prevent desktop lockups from occurring due to a non-responsive application (AT or application being accessed). These improvements, while awesome, had the side effect of Orca's modifiers keys seeming to be "stuck". That issue was addressed with this fix [1]. Now the desktop doesn't hang and the Orca modifier doesn't get "stuck," which is great. Unfortunately, assuming that commands are not consumed apparently has the side effect of Orca commands sometimes being passed through to the application. Examples: * In a text editor, using an Orca command (e.g. Orca+f to get font information) can result in an 'f' getting added to the document and/or overwrite mode being toggled (in the desktop layout). * Using Orca's flat review commands to examine screen contents without changing them can change those contents by inserting a character (laptop layout) or moving the caret (desktop layout). I chatted with Mike via IRC last week about this. He said, "I think it might be incorrectly thinking that Orca isn't responding. I'm not really sure. I'm thinking of having it ping the process and resume delivering events when a reply is received." Code freeze is in six days, and we really need a fix for this situation, be it the one described or something else. [1] http://git.gnome.org/browse/at-spi2-core/commit/?id=2cf16b3ec3777d1337e02d6a7850290a259eda5b
I'm hoping that fddaf0 will fix this, but I haven't seen the problem recently and don't really understand why it is happening. Please re-open if someone sees it again.
Afraid I am re-opening. I have a test case: 1. Configure Orca to display the infamous main window and to confirm before quitting. 2. Move focus to the Quit button. 3. Press -- and do not release -- the Orca modifier along with Space. Expected results: Only the Orca preferences dialog box would appear. Actual results: The Orca preferences dialog appears, but so does the quit confirmation dialog. Granted, this is a bit of an extreme case. I mean why would anyone hold down the keys for that long without releasing them, and who sees the main window (which is hidden by default in GNOME 3.x)? But given how periodic/sporadic the bug is, at least this is reliably reproducible. What users have been reporting (but which I have not been able to reproduce since Mike's earlier adjustments for this issue) occurs in documents, and terminals, and other more "normal" use cases.
It looks as though the following is happening: - at-spi2-atk sends a keystroke notification to the registry, then waits for a reply. Since Orca is an AT-SPI client, we re-enter the main loop using the default context, rather than creating a separate context as is normally done. I'm not sure if this behavior is still needed (it might be left over from when FDO#30574 was an issue and we couldn't switch contexts to create a separate context just for DBus connections / when dbus_connection_read_write_dispatch was used instead of creating a main loop context), but I don't want to change this behavior this close to code freeze. - The registry daemon sends messages to keystroke listeners to ask whether the key should be consumed. - Meanwhile, Orca is busy sending cache update notifications, which takes a while for some reason, so it doesn't process the "should this be consumed" notification right away. If we were creating a separate main context, then this idle wouldn't get executed here. Anyway, I've increased the timeout used by the registry from 1 second to 3 seconds, so that it will be somewhat less aggressive about deciding that a process is hung. This might not be sufficient on a slower system, and I'd like to figure out if it's safe to always create a new main loop context in at-spi2-atk when sending keystroke notifications (not just if we're not an AT) and possibly change that behavior for 3.6, so I'm leaving the bug open for now.
I think that we can keep this bug open as described by Mike, but remove the GNOME target of 3.4. I think it's as good as we can get it in time for the release.
Not often happening this issue my system, but now happened me before I not restarted my system. For example, when I do a where am I command in Skype tree view, I activated Capslock+Enter command an unvanted chat window with a contact. My machine have an Intel Dualcore t2300 CPU with 1,73 GHZ, 2 GB ram, so my machine relative not slow. Some time happening this issue under GNOME Terminal too. When I using flat review for example when I installing updates, Orca laptop flatreview command letter parts are typed with terminal, and flatreview commands doesn't working right this situation. For example, if this problem are happening, unable to move between lines with Orca modifier+u and Orca modifier+o commands. Attila
[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!]
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.