1966812 - Support getting character bounds for end of line insertion point

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Some accessibility clients (e.g. Windows Text Cursor Indicator) need to be able to retrieve the rectangle for the character at the caret. In bug 1951833, I'm fixing this for line feed characters. However, TextLeafPoint::CharBounds doesn't properly support this for the end of line insertion point; i.e. when mIsEndOfLineInsertionPoint is true. Text Cursor Indicator seems to cope without this, but we should probably support it for completeness and/or better accuracy.

I think we can do this by getting the previous character's rectangle and then returning (prevX + prevW, prevY, 1, 1) or similar.

Comment 1

[James Teh [:Jamie]]

We're actually going to need this for UIA. STR:

1. Enable Windows Text Cursor Indicator.
2. Open this:
   data:text/html,<textarea>a%0A%0A</textarea>
3. Move to the final (blank) line.
   • Expected: The Windows Text Cursor Indicator moves to the final line.
   • Actual: Firefox's text insertion cursor moves to the final line. However, the Windows Text Cursor Indicator is on the first blank line.

Comment 2

[James Teh [:Jamie]]

I think we can do this by getting the previous character's rectangle and then returning (prevX + prevW, prevY, 1, 1) or similar.

That won't work for comment 1; that'll just result in the same problem. We need some way of getting the coordinates of the actual caret in this case. We do have HyperTextAccessible::GetCaretRect and we do send that to the parent process with caret events, but it's a bit messy for various reasons.

Comment 3

[James Teh [:Jamie]]

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

We need some way of getting the coordinates of the actual caret in this case.

It'd be better if we could get the coordinates for where the caret would be if it landed here, since the caret might have actually moved somewhere else since this point was created. I'm not sure if that's possible though.

Comment 4

[James Teh [:Jamie]]

Eitan, based on our chat, are you planning to work on this? Totally fine either way. I just want to know so I don't put time into it if you're already on it (or will be soon).

Comment 5

[James Teh [:Jamie]]

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

It'd be better if we could get the coordinates for where the caret would be if it landed [at the end of line insertion point], since the caret might have actually moved somewhere else since this point was created.

When mIsEndOfLineInsertionPoint is true, we could perhaps:

1. If mOffset < TextLength(mAcc), Use (prevX + prevW, prevY, 1, 1) as suggested in comment 0.
2. If mOffset == TextLength(mAcc), get the bounds of mAcc and use (accW - 1, accH - 1, 1, 1). That covers comment 1 (the line feed at end of input case). We could further restrict this so that we only do it if the character at mOffset - 1 is a line feed if that makes more sense.

Comment 6

[Eitan Isaacson [:eeejay]]

I'm working on this, yes :)

Note, I'm not changing the width of the caret to align to the start of the character because it would be wrong for vertical or rtl text.

Comment 7

[James Teh [:Jamie]]

Per discussion with Eitan, we think the best thing to do here is to use the caret rect if mIsEndOfLineInsertionPoint && this == TextLeafPoint::GetCaret(mAcc). That means we need to cache the caret rect on the DocAccessibleParent and unify the way we query the caret rect.

I didn't do this unification in bug 1828295 because HyperTextAccessible::GetCaretRect takes a widget, which is weird for RemoteAccessible. It does this because Windows needs to set up the system caret in the correct OS widget (HWND) and pop-ups have separate OS widgets. However, it just occurred to me that RemoteAccessible::GetCaretRect can just return the widget for OuterDocOfRemoteAccessible(). That also means we can unify Windows AccessibleWrap::UpdateSystemCaretFor, since the unified GetCaretRect can return both a rect and a widget in all cases.

Comment 8

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1966812 - Cache rect bounds in DocAccessibleParent. r?Jamie

Moved GetCaretRect to HyperTextAccessibleBase. I could see this living
in TextLeafPoint, but it is a bit confusing when a point is a caret and
when it is a simple offset. I think we would need to either add an
mIsCaret field to the class, or have a special static CaretBounds
method.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/12c9970d79e8
https://hg.mozilla.org/integration/autoland/rev/abf91f0d19d7
Cache rect bounds in DocAccessibleParent. r=Jamie

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/83bc2bce51a8
https://hg.mozilla.org/integration/autoland/rev/ae6f4a626e90
Revert "Bug 1966812 - Cache rect bounds in DocAccessibleParent. r=Jamie" for causing ba failures @ browser_caret_rect.js

Comment 11

[amarc]

Backed out for causing ba failures @ browser_caret_rect.js

• Backout link
• Push with failures
• Failure Log

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/75f3d184f946
https://hg.mozilla.org/integration/autoland/rev/5f34c29bdb1f
Cache rect bounds in DocAccessibleParent. r=Jamie

Comment 13

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/5f34c29bdb1f