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

[Michael Weghorn]

On 2024-06-11 10:48, Michael Weghorn wrote:
> 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

PPS: Now actually CC'ing the accessibility mailing list as mentioned in 
my previous email...
-------------- 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/ec1e8535/attachment.sig>