Open Bug 1946320 Opened 1 year ago

TextLeafPoint::FindTextAttrsStart behaves incorrectly if it reaches a non-text sibling

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

(Blocks 1 open bug)

Details

This code in FindTextAttrsStart stops walking through siblings if we hit a non-text sibling in the same container. Before we started walking across containers (bug 1927001), that was expected (albeit undesirable), since we would return the same point if we hit a non-text boundary. Now, though, I think it's incorrect. Once we get out of the loop, for eDirPrevious, we then just return lastPoint. Consider this:
<img ...>abc
If you have a TextLeafPoint on "a" and you call FindTextAttrsStart with eDirPrevious, the loop will try the <img>, see it's not text and break. Then it'll just return the origin (this). In reality,I think it should return the <img>.
Interestingly, I think it's okay for eDirNext because we call NextLeaf in that case. That was intended to hop to the next container, but in this case, it'll hop to the next sibling, which is actually what we want, even if the comment is misleading for this case.
I'm not sure how we can actually reproduce this at the moment. HyperTextAccessible won't trigger this because it always specifies eDirPrevious with aIncludeOrigin=true. We might be able to reproduce it with UIA.

You need to log in before you can comment on or make changes to this bug.