Hi!
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 Rust atspi [2] is 48 bytes. If all children
were to be returned, this would be a D-Bus message exceeding 96 GiB.
This is impractical and it cannot be performed legally either, because
the maximum D-Bus message size 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.
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 the visible and showing objects only? Either would be
more practical than try and send 96 Gigs ;)
The `fama11y-tree` branch linked below `calc-demo` looks at any object
exposing more than 100,000 children and then returns information on that
object and not call `GetChildren`.
The main branch will call `GetChildren` and wait indefinitely for calc
to finish.
Thanks!
Luuk van der Duim
Please cc me as I am not on the list.
[1]: <https://github.com/luukvanderduim/fama11y-tree/tree/calc-demo >
[2]: <https://github.com/odilia-app/atspi>
[3]:
<https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages>
[4]: <https://bugs.documentfoundation.org/show_bug.cgi?id=156657>
