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

[Luuk van der Duim]

Thanks for your thoughts! I will gladly expand a bit.
>
> LibreOffice doesn't proactively send a list of all cells, so one 
> question could be why the screen reader/AT is querying all of the 
> children (cells) in the first place, rather than only those it's 
> interested in for some reason, e.g.
>
> * the currently focused cell
> * the first and last selected cell to announce something like "cells 
> A1 to C10 selected"
We absolutely do that, however we're also trying to be ahead of the game 
and get the data before the object obtains focus.
> * If it's a tool for analysis, one approach might be to just query the 
> first N children initially, and query more on demand, with N being a 
> reasonably manageable number.

Not every object will support `Collection` and, there is no other way to 
get a range of children other than repeatedly calling 
`Accessible::GetChildAtIndex`.

`Accessible` is the only interface that every object support.

>
> Can you expand a bit more on the specific use case you have in mind 
> where ATs have to query all children?

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.

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.

The `Accesslble` interface is the most used and trusted in general. 
Other interfaces may be helpful but implementations do vary.
>
> The discussion in tdf#156657 and the referenced GTK issue [1] have 
> some considerations on what to potentially do alternatively, with no 
> definitive approach being outlined yet (e.g. what to do when part of 
> the selection is off-screen). Input welcome! :-)

In practical sense, if your array of children is huge, please make sure 
to not exceed D-Bus message limit of 128MB.

>
> I think a clear concept of how to handle such scenarios in general, 
> not just for LibreOffice Calc, would be useful, rather than every 
> application that has a11y objects with a large amount of children 
> trying to come up with a custom/own solution.

I fully agree, a general rule for reliable behaviour would be 
preferable. However, I think most hope the issues will be resolved by 
AT-SPI's successor. But introduction and adaptation may take years. In 
the mean time, I hope we can agree to do something more sensible.

>
>> The `fama11y-tree` branch linked below, `calc-demo`, checks for any 
>> object exposing more than 100000 children and then returns 
>> information on that object and not call `GetChildren`.
>
> As mentioned above, not unconditionally retrieving all children on the 
> AT side generally sounds reasonable to me.

I disagree. There is no use case for a reply this big, it is not the 
actual size of the sheet anyway and it is not a legal reply-message.

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.

Thanks in advance!