[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