Closed Bug 1169238 Opened 9 years ago Closed 10 months ago

When one table cell has selected text, other cells incorrectly report selection

Categories

(Core :: Disability Access APIs, defect)

x86
Windows
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox113 --- fixed
firefox114 --- fixed
firefox115 --- fixed

People

(Reporter: Jamie, Unassigned)

References

(Blocks 1 open bug)

Details

Str:
1. Open this URl:
data:text/html,<body contentEditable="true"><table><tr><td>ab</td><td>cd</td></tr.</table></body>
2. Focus on the document.
3. Use the arrow keys to move the cursor to the "A".
4. Press shift+rightArrow to select "a".
5. Obtain the accessibles for both table cells.
6. Call IAccessibleText::nSelections on the first cell.
Result (correct): 1
7. Call IAccessibleText::selection(0) on the first cell.
Result (correct): (0, 1)
8. Call IAccessibleText::nSelections on the second cell.
Expected: 0
Actual: 1
9. Call IAccessibleText::selection(0) on the second cell.
Expected: E_INVALIDARG
Actual: (0, 2)

This causes severe problems when trying to retrieve selected text when all or part of the text in a table is selected.
Blocks: texta11y
> Result (correct): (0, 1)
> 8. Call IAccessibleText::nSelections on the second cell.
> Expected: 0
> Actual: 1

So I think this is because of the weird bit in HyperTextAccessible::GetSelectionDOMRanges() that tries to get an editor and then if it gets one sets the node to be the editor's root node.  That makes sense for form controls I guess? but it doesn't make much sense for contenteditable I think.

> 9. Call IAccessibleText::selection(0) on the second cell.
> Expected: E_INVALIDARG
> Actual: (0, 2)

So this is because we get a range because of the above, but its content is disjoint with the content for the accessible.  However HyperTextAccessible::SelectionBoundsAt assumes the range is not disjoint with its content so if an end point is not underneath this node we assume the range extends past that end and say the range end is 0 / text length.  imho the bug here is the same as above GetSelectionDOMRanges() returned a range when it should not.

Fixed by CTW.

Depends on: 1782873
Severity: normal → S3

This is resolved by Cache the World, which is enabled by default in Firefox 113.

Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.