1973154 - Accessibility treats selection spanning only empty containers as no selection

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Test case:

data:text/html,<div id="c1">hi<span id="c1_span1"></span><span id="c1_span2"></span>hi</div><script>window.getSelection().setBaseAndExtent(c1_span1, 0, c1_span2, 0);</script>

https://searchfox.org/mozilla-central/rev/beba5cde846f944c4d709e75cbe499d17af880a4/accessible/tests/mochitest/textselection/test_general.html#217

For RemoteAccessible, querying the document or div Accessibles will report no selection; i.e. TextLeafRange::Selection will return 0 ranges, HyperTextAccessibleBase::SelectionCount will return 0. As I write this, this does actually work with LocalAccessible. That's not particularly useful though, since most documents are remote now, and I am looking to unify this code.

This occurs because the spans don't occupy HyperText characters, so the only way to represent this with HyperTextAccessible is (c1, 2, 2), which looks like a collapsed range, even though it isn't in the DOM. That means that CroppedSelectionRanges removes it, believing it to be collapsed.

We can represent this without loss of information in TextLeafRange: (c1_span1, 0, c1_span2, 0). However, selection is currently always retrieved from HyperTextAccessible first. The correct fix here is to make TextLeafRange the primary source of truth for selection, have cropping occur in TextLeafRange and only then convert to HyperText offsets. This is quite a big lift though because selection events are currently based on HyperText.

I don't think this is particularly important because a selection like this is effectively empty as far as the user is concerned, so it isn't really useful. Fixing this would be purely for correctness, unless there's a use case I'm missing.