a11y AT-SPI: get_child_count implementation iterating over all children causes freeze for objects with many a11y children
The current implementation for retrieving the Accessible::ChildCount
property for AT-SPI in gtk_at_spi_context_get_child_count
iterates over all children to determine the amount of children: https://gitlab.gnome.org/GNOME/gtk/-/blob/a9e4993184605bc70e930b5c1e69d8f49c689c76/gtk/a11y/gtkatspicontext.c#L1793-1815
This results in a freeze in applications that have objects with many children, e.g. a Calc table in LibreOffice, which has more than a billion cells.
Steps to reproduce
- Start LibreOffice Calc from a current LibreOffice development version with so-called gtk4 VCL plugin (i.e. build with
--enable-gtk4
, start with environment variableSAL_USE_VCLPLUGIN=gtk4
- start Accerciser and navigate through the a11y hierarchy of the LibreOffice app -- in particular: navigate to the document object and further from there
Current behavior
LibreOffice becomes unresponsive, freezes.
Debugging shows that this is because gtk_at_spi_context_get_child_count
wants to iterate over all children, s. backtrace below.
Expected outcome
The application should continue to be responsive.
Version information
- Debian testing
- gtk self-compiled from git main branch as of commit a9e49931
- LibreOffice self-compiled from git master branch as of commit eb4ac533ae358bb596ed60d5a65682799bf375a0
Additional information
- GDB backtrace:gdb_backtrace_libreoffice_gtk4_freeze.txt
- Making it possible for GtkAccessible implementations to override the default implementation might be a solution.