1573166 - Follow-up of Bug 1319273: a11y: HyperTextAccessible::CharBounds() returns 0,0 coordinates at ends of lines

Status: NEW

(Core :: Disability Access APIs, enhancement, P3)

Description

[Samuel Thibault]

Attachment: buggy_caret_tracking_demo_script.py

Hello,

I have attached a test script to see the behavior under Linux: when the caret is put at the end of a line, HyperTextAccessible::Charbounds() returns a (0,0,0,0) rect. This is the same kind of issue as Bug 1319273: since there is no character here, firefox returns an empty box.

When the line is non-empty, a workaround for a screen magnifier is to take the bounds of the last character of the line. But when the line is empty, there is really no character to get the bounds of.

In such a case, it would be useful to still return the rect of the caret itself, even if with zero width (this is what gtk does for instance), so that the screen magnifier can show users which empty line they are going through.

I however don't know how I could get the rect of the caret?

Samuel

Comment 1

[James Teh [:Jamie]]

When you refer to an empty line (in non-empty text), do you mean in a textarea or something more like a contentEditable containing an empty paragraph?

The following three examples are all quite different, but all contain "empty" lines:

1. Simple empty input. This should be covered by your previous patch:
   data:text/html,<input>
2. textarea where the second line is empty (control+home then down arrow will land on the blank line, caret offset will be 2):
   data:text/html,<textarea>a%0a%0ac</textarea>
3. contentEditable where the second paragraph is empty (control+home then down arrow will land on the blank line, caret will be in the second paragraph at offset 0):
   data:text/html,<div contentEditable><p>a</p><p><br></p></div>
   Your previous patch should handle this case as well, since the paragraph is empty (even though it's part of a larger whole).

Am I correct, then, that the only problematic case for empty lines here is case 2 above? In that case, there is a character as far as accessibility is concerned: the new line ("\n"). (There probably isn't a character as far as layout is concerned, though; I'm not sure.)

One concern I have with trying to use the caret bounds for a new line character is that we could only do that if the caret was actually at that offset. That means CharBounds might return a different result for a given offset based on whether the caret was at that offset or not.

Comment 2

[Samuel Thibault]

The second case is the problematic case, yes.

Yes, there is a character in accessibility terms (thus the possibility for the a11y API to get its extents), but in layout terms there isn't, so no extents is returned.

One concern I have with trying to use the caret bounds for a new line character is that we could only do that if the caret was actually at that offset
That means CharBounds might return a different result for a given offset based on whether the caret was at that offset or not.

Ah, I meant to return the caret bounds as if the caret was there ; so that the result would indeed be the same, be the caret there or not.

Comment 3

[Vegas Balboa]

Attachment: same problem

Thanks from naforole1977.