[libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`

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...

--
To unsubscribe e-mail to: accessibility+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/accessibility/
Privacy Policy: https://www.documentfoundation.org/privacy