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

Michael Weghorn m.weghorn at posteo.de
Tue Jun 11 08:48:21 UTC 2024


On 2024-06-11 10:07, Samuel Thibault wrote:
> Michael Weghorn, le mar. 11 juin 2024 07:55:47 +0000, a ecrit:
>> The feedback I've received from a11y experts so far is that off-screen doc
>> content should *generally* be exposed on the a11y level, and limiting Calc
>> to not do that with its huge amount of table cells is meant to be an
>> exception to the rule in that regard (see e.g. the discussion in [2] and
>> tdf#156657).
> 
> I guess we can have the same kind of issue with a >>100 pages writer
> document?

I would expect that there should still be way less objects than for the 
Calc case and the child count of each individual object will be lower 
(when Writer pages are reflected in the a11y tree, which they currently 
are not).

In a first quick experiment with a local WIP branch, nothing was 
obviously broken right away when opening a ~800 pages Writer doc (but 
just containing simple text, nothing more complex) and moving around a 
bit while Orca was running or inspecting the tree using Accerciser.

But of course, if some AT (or some underlying library) recursively 
queries and caches the whole tree and very complex documents are 
involved, then similar performance issues seem possible. (macOS and Win 
also need explicit testing, of course.)

To me, this whole topic seems to be basically the same as the 
anticipated and still-to-be-solved performance aspect with the push 
approach that the alleged AT-SPI2 successor (codename "Newton") already 
mentions in its concept, see e.g.
https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/142

Hopefully, a clear concept will come out of the work on the new protocol.

Otherwise, as long as the underlying platform a11y protocols are 
pull-based and given the input I've received up to this point, I tend to 
think that ATs actively querying the tree are primarily responsible for 
limiting that to a reasonable amount of information, but I'm thankful 
for any guidance here...

Technically, platform-specific handling of how much information is 
exposed would be possible, obviously adding a certain amount of 
complexity and maintenance burden.



PS: CC'ing the accessibility mailing list, where people with more 
insights on the AT side are subscribed. Input welcome!
For reference: Thread starts here:
https://lists.freedesktop.org/archives/libreoffice/2024-June/092039.html
-------------- 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/20240611/acc0df90/attachment.sig>


More information about the LibreOffice mailing list