mate-search-tool + accessibility clients = unresponsive everything

[joanmarie]

Steps to reproduce:

1. Launch mate-search-tool
2. Launch the Accerciser accessibility inspector
3. In Accerciser:
   1. Select "mate-search-tool" in the app list on the left
   2. Select the "Event Monitor"
   3. Check the "object" checkbox,
   4. Select the "Selected application" radio button"
4. Return to mate-search-tool and:
   1. Choose a folder with a lot of files
   2. Type a single letter (e.g. "a") to search for
   3. Once the search has gotten underway, repeatedly press Tab to change focus within mate-search-tool

Expected results: Tab would immediately and reliably change focus every time, Accerciser would not become unresponsive, CPU consumption would not spike, etc.

Actual results: For me, Tab stops changing focus within mate-search-tool, '"Accerciser" is not responding" dialogs appear, CPU spikes, fans become quite audible, etc.

Impact: mate-search-tool + Orca is a non-starter.

Notes: This was a problem from the gnome-2 days that seems to have persisted. I gave Orca some workarounds so that it would not become completely unresponsive. But those workarounds involve unregistering globally for events it needs to receive to provide access to other applications. So that's really not an option. :(

Related: https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/133

CC: @cwendling

[lukefromdc]

I was just unable to duplicate this with mate-search-tool on Debian Unstable with MATE from git master. Might be a version or underlying OS difference, but accerciser just kept going, with text scrolling in the event monitor as I kept shifting focus in mate-search-tool with the tab key

[joanmarie]

If @cwendling cannot repro it, I can try to create an dedicated tool/script to show the problem.

[cwendling]

Actual results: For me, Tab stops changing focus within mate-search-tool, '"Accerciser" is not responding" dialogs appear, CPU spikes, fans become quite audible, etc.

I cannot reproduce Tab being unreliable in mate-search-tool, it sometimes becomes slightly laggy, but not often and it's reliable (always steps the number of hits). Note that I did not run Orca, as not mentioned in the steps.

However, I reproduce that Accerciser becomes locked up, CPU spikes, and it seems to affect key input in other apps like Firefox right now. (which works, but is terribly laggy while writing this message while Accerciser is crumbling under load)

I'm not sure what we can do here on our end? Should be manually overload something to reduce the amount of bounds-changed events being emitted? I'm not entirely sure which objects are responsible for all of those, it seems to come from a little bit of everywhere, although I don't see anything actually moving apart the number of found elements and the content of the tree view… did you pinpoint more precisely what is the cause? If it's only the label updating, it might be fairly easy to workaround this and throttle updating it accessible label.

[lukefromdc]

Any chance this is an accerciser bug and not a mate-search-tool bug?

[cwendling]

One could argue there is no bug anywhere, but the reality seems to be that we generate so may events that it effectively drowns anybody listening. As @joanmarie said on the report, it probably should either be throttled when possible by either (or both) the toolkit or at-spi2, but that's not currently the case. And whether that can be generic probably has to be assessed as well.

[cwendling]

FWIW, many of the bounds-changed events seem to be plain GTK, I see a spam of those even with a sample app that just has a window and a button…