[a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`

[Michael Weghorn]

Thanks for the additional explanations!

On 2024-06-07 15:20, Luuk van der Duim wrote:
> What any screen-reader/AT would like is to offer best response times to 
> users by caching objects up-front to minimize IPC round trips between AT 
> and application.
> 
> For `atspi` we would like to offer a cache for any AT to use. A tree 
> with a subset of data and keep that up-to-date by listening for signals.
> 
> You are right LibreOffice does not proactively send a 96G array but it 
> does offer `GetChildren` on the public bus which will.

When it comes to the AT-SPI `GetChildren` method, LibreOffice only 
implements functions to get the child count and to get a child at a 
given index, calling both of which should be unproblematic 
performance-wise by themselves (i.e. in particular when not iterating 
over all children).

If you're using the gtk3 VCL plugin (UI variant), the `GetChildren` 
implementation is provided by ATK/atk-adaptor (which is now part of the 
at-spi2-core git repo) and iterates over all of the children, causing 
the problems you describe.

> It means one can never call `GetChildren` on that object because it 
> makes no sense. It makes naively building a tree like the example 
> program [1] does is impossible because LibreOffice Calc wants to return 
> something that in practical terms no-one can handle.
> 
> (...)
> 
> In practical sense, if your array of children is huge, please make sure 
> to not exceed D-Bus message limit of 128MB.
> 
> (...)
> 
> Could LibreOffice please limit the reply-message to something reasonably 
> sized? (Or at least legally sized?) This is currently a bit of a 
> foot-gun with a public interface.

I've submitted a merge request to at-spi2-core to limit the maximum 
amount of children to return, similar to what an earlier change did when 
using the Collection interface:
https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/159

Does that help?

(Of course, this doesn't mean that the way that LibreOffice shouldn't 
eventually optimize handling of how Calc cells are reported on the a11y 
level altogether, but as I mentioned, there are still open questions 
related to that, so that IMHO needs more discussion + effort to implement.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20240610/ec15ea67/attachment.sig>