1756081 - Unicode left to right marks break text navigation in HTML text fields

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

STR (with the NVDA screen reader):

1. Open this test case:
   data:text/html,<input type="text" value="&%23x0200e;ab&%23x0200e;cd&%23x0200e;ef&%23x0200e;gh">
2. Focus the text field.
3. Move to the beginning by pressing home.
   • Observe: NVDA says "a"
4. Move character by character with the right arrow key.
   • Expected: NVDA says: b, c, d, e, f, g, h, blank
   • Alternative expected: NVDA says: a, b, left to right mark, c, d, left to right mark, e, f, left to right mark, g, h

There are two issues here:

1. The caret offset isn't aligned with the text offsets.
2. The caret hits the left to right marks, even though they aren't rendered visibly.

Interestingly:

1. This fails in an input or a textarea, but works fine in a contenteditable. In the contenteditable, the caret doesn't hit the left to right marks and the offsets are aligned. This discrepancy confuses me.
2. In Chrome, the caret always hits the left to right marks and they are rendered in the a11y tree.

Possible fixes:

1. We need to render the left to right marks into the a11y tree for HTML text fields. That probably means using the DOM text instead of the text from layout for these fields.
2. The caret shouldn't hit the left to right marks and the offsets should be aligned.
3. We just align the offsets. The caret will appear to hit the same character twice, but that's better than it being out of alignment for every character thereafter.

I notice we treat text fields specially in ContentToRenderedOffset. Could that be the cause for the unaligned offsets here and will changing that break anything else?

Practical impact: If you paste any content into a text field containing left to right marks (e.g. the Windows version information), editing in the field is unusable.
Originally reported in NVDA issue: https://github.com/nvaccess/nvda/issues/13355

Comment 1

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #0)

I notice we treat text fields specially in ContentToRenderedOffset. Could that be the cause for the unaligned offsets here and will changing that break anything else?

This was originally done in bug 850987 to fix performance problems with large textareas. It was further extended to pre-formatted text (e.g. <pre>) in bug 1766954, also due to performance problems. This suggests that we can't just remove this, since we'd regress performance in these cases.