TextLeafRange::VisibleLines/ITextProvider::GetVisibleRanges incorrectly handle text that is scrolled out
Categories
(Core :: Disability Access APIs, 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.
Description
•