[Webkit-unassigned] [Bug 233383] AX: aria-owns in trees results duplicate rows, third level rows not being exposed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=233383

--- Comment #16 from Sepand Parhami <sparhami at apple.com> ---
(In reply to Tyler Wilcock from comment #15)
> Comment on attachment 445924 [details]
> Patch
> 
> This would be a progression in terms of behavior, and probably a good step
> towards improving aria-owns support for all elements, but I worry that the
> performance might be untenable. With this latest patch, we call
> ariaOwnsReferencingElements for each DOM and aria-owns child. Our
> implementation of ariaOwnsReferencingElements does a scan of every element
> starting from the root. So for a tree with a lot of children, and given a
> large document, I image this could cause performance issues.

Let me explore to see if there is a lighter weight way of doing this. I'm not sure how important the `ariaTreeRows` method being virtual is. I could perhaps implement the traversal in a separate function and just keep track of an array/set of visited nodes or just pass it along in the `ariaTreeRows` signature, but I'm not sure what the right style is here. Perhaps I could also just keep track of the current ancestry path rather than looking at all the visited nodes.

> It's unfortunate that we don't have an efficient way to find
> ariaOwnsReferencingElements. Ideally we would cache this somewhere as we
> build the tree, and then these lookups would be fast. But that would
> probably be a big project.
> 
> > I added a circular reference to the existing test case, but can make it a separate file if that makes more sense.
> I would prefer a separate file so there's a clear distinction that
> accessibility/mac/treeitem-row-delegation.html tests the behavior of a
> well-formed tree, while this other test specifically ensures we don't crash
> with a circular reference.
> 
> Was this version of the patch[1] vulnerable to circular references based on
> the circular reference test case you added in your latest patch?
> 
> [1]: https://bugs.webkit.org/attachment.cgi?id=445585&action=prettypatch

Yep.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211208/2412d8d0/attachment.htm>