Open Bug 1945010 Opened 14 days ago

TextLeafRange::VisibleLines/ITextProvider::GetVisibleRanges incorrectly handle text that is scrolled out

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

(Blocks 2 open bugs)

Details

Bug 1901464 implements UIA's ITextProvider::GetVisibleRanges and thus TextLeafRange::VisibleLines. TextLeafRange::VisibleLines doesn't correctly handle lines that are scrolled out where the scroll container is a descendant of the provided aContainer Accessible argument. Such lines might intersect with aContainer's bounds, but the scroll container could be a descendant of aContainer and thus exclude the line. Being able to specify aContainer helps mitigate this in some cases. For example, consider a textarea sized to 1 line of text containing 3 lines of text. If VisibleLines is called passing the textarea as aContainer, it will correctly exclude the second and third lines. However, if called with the document as aContainer, it will return all 3 lines.

Fixing this is going to be tricky. We do have sufficient information in the RemoteAccessible cache to figure this out - hit testing uses this to deal with this exact problem - but it's not readily available to TextLeafRange, nor is it abstracted in such a way that it can be used for both Local and Remote Accessibles. We could hit test each rect and exclude it if its range's common ancestor isn't visible at that point, but: that's expensive; it's unclear what point in the rect to hit test (the centre?); that will exclude the rect if there is something transparent on top of it; etc.

Chromium's ITextProvider::GetVisibleRanges implementation has the same bug and we're not sure how much this method is used, so fixing this isn't high priority. However, it's definitely incorrect.

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