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

[Michael Weghorn]

Hi,

thanks for bringing this up.

On 2024-06-06 23:44, Luuk van der Duim wrote:

> While working on fama11y-tree [1], an AT-SPI2-bus objects tree example, 
> I found that LibreOffice Calc has an object that exposes 2^31 children 
> on its `Accessible` interface.
> 
> (LO version: 24.2.3.2 x86_64, xubuntu 24.04)
> 
> The object:
> 
> Inspecting object with high child count
> Object: name: "Sheet Sheet1", role: "table", description: ""
> Interfaces: "InterfaceSet(BitFlags<Interface>(0b10100000000110001, 
> Accessible | Collection | Component | Selection | Table))"
> child_count: 2147483647, ObjectRef size: 48, collection size: 96.00 GB,
> Application: name: soffice, role: application
> 
> If `GetChildren` is called on that object, Calc freezes and the AT (eg. 
> screen-reader) performing the call would wait for a response.
> 
> Each object-reference in `atspi` (Rust crate) [2] is 48 bytes. If all 
> children were to be returned, this would be a D-Bus message of 96 GiB. 
> This is impractical and cannot be performed legally either, because the 
> maximum size of a D-Bus message is 128 MiB. [3]
> 
> The main problem however is that calc freezes and that screen-readers 
> need to take measures to avoid calc from sending huge numbers of children.

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"
* 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.

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

> There is an existing bug report by Joanmarie Diggs that is relevant, 
> #156657 [4].
> 
>  From that discussion I understand that the table already contains more 
> children than it exposes, maybe the exposed number of children could be 
> reduced further to the maximum number of children mentioned in the 
> thread (65535) or to the visible and showing objects only. Either would 
> be more practical than trying to send 96 Gigs 😉

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! :-)

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.

> 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.

[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/6204
-------------- 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/20240607/d37af7f1/attachment.sig>