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: applicationIf `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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
