Bug 269072 – AX: WebKit fails to emit newlines between container nodes when serving AXStringForTextMarkerRange off the main-thread

• Component: Accessibility
• Status: RESOLVED FIXED

[Tyler Wilcock]

...

[Radar WebKit Bug Importer]

<rdar://problem/122648346>

[Tyler Wilcock]

Created attachment 469795 [details]
Patch

[Tyler Wilcock]

Created attachment 469797 [details]
Patch

[Joshua Hoffman]

Comment on attachment 469797 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=469797&action=review

> Source/WebCore/accessibility/AXTextMarker.cpp:414
> +    if (isForward) {
> +        for (size_t i = startIndex; i > endIndex; i--)
> +            append(children.at(i - 1));

This feels counter-intuitive to me (or may need a comment explaining)—why do we traverse backward in the children when appending the children when isForward == true?

[Tyler Wilcock]

(In reply to Joshua Hoffman from comment #4)
> Comment on attachment 469797 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=469797&action=review
> 
> > Source/WebCore/accessibility/AXTextMarker.cpp:414
> > +    if (isForward) {
> > +        for (size_t i = startIndex; i > endIndex; i--)
> > +            append(children.at(i - 1));
> 
> This feels counter-intuitive to me (or may need a comment explaining)—why do
> we traverse backward in the children when appending the children when
> isForward == true?
This is a good question. I think traversing forward would be fine, but this bit is copied exactly from AccessibilityObject::appendChildrenToArray, so I think it makes sense to keep consistent. These functions differ for now, but once all of this text-marker logic is not specific to AXIsolatedObject, we may want to share the original AccessibilityObject::appendChildrenToArray implementation, so want to keep similarities where we can to make that more straightforward.

[EWS]

Committed 274664@main (53c3857f5cea): <https://commits.webkit.org/274664@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 469797 [details].