Closed Bug 2012651 Opened 1 month ago Closed 1 month ago

The Text Cursor Indicator would not update its position until press arrow key or click on contentarea

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
Desktop
Windows 11
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
149 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- wontfix
firefox147 --- wontfix
firefox148 --- fixed
firefox149 --- fixed

People

(Reporter: alice0775, Assigned: Jamie)

References

(Blocks 3 open bugs, Regression)

Details

(Keywords: nightly-community, regression, Whiteboard: [uiaFastFollow])

Attachments

(2 files)

Bug 2012651: Fix caret coordinates at the start of a paragraph preceded by a line of other text. r=morgan!
48 bytes, text/x-phabricator-request
Details | Review
Bug 2012651: Fix caret coordinates at the start of a paragraph preceded by a line of other text.
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-beta+
Details | Review

When I test Bug 2012252, I found another bug.

Steps to reproduce:

  1. Start > Settings > Accessibility > Text cursor> turn Text cursor indicator to on
  2. Open data:text/html,<script>document.designMode="on";</script><body><p><br></p></body>
  3. Type text

Actual results:
The Text Cursor Indicator would not update its position.

Expected results:
The text cursor indicator should follow the text insertion point.

MS Edge/Google Chrome works as expected.

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=fc75de6654182fd09d97d4d34e9b96c6ea7895e8&tochange=327aa1eaa276c313c05ed83174c06958ed788799

See Also: → 2012252

Set release status flags based on info from the regressing bug 1951833

:Jamie, since you are the author of the regressor, bug 1951833, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

status-firefox147: --- → affected
status-firefox148: --- → affected
status-firefox-esr140: --- → affected
Flags: needinfo?(jteh)

Investigation note: Once there is text before it, moving the caret to the <br> and then calling UiaTextRange::GetBoundingRectangles on the caret range returns nothing. No idea why yet.

Blocks: uiatext
Severity: -- → S3
status-firefox147: affected → ---
status-firefox148: affected → ---
status-firefox-esr140: affected → ---
Whiteboard: [uiaFastFollow]
status-firefox147: --- → affected
status-firefox148: --- → affected
status-firefox-esr140: --- → affected
Flags: needinfo?(jteh)
Flags: needinfo?(alice0775)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)

Does this also depend on the accessibility.uia.enable pref?

Setting accessibility.uia.enable to 0 and 1 did not fix this issue.

Flags: needinfo?(alice0775)
Assignee: nobody → jteh
Status: NEW → ASSIGNED
Blocks: texta11y, boundsa11y

This was breaking Text Cursor Indicator when typing into an impacted text box.
This was caused by a cascade of problems:

  1. When the caret is at the end of the line before the paragraph, it is actually at the end of line insertion point. Previously, we weren't identifying that correctly.
  2. This happened because the caret was positioned after the first line in the container, but because TextLeafPoint can't represent a position that isn't within a leaf, we were translating it to the first character of the paragraph, thus losing the information we require to determine that it is an end of line insertion point. We now handle this case explicitly when translating the HyperText caret offset into a TextLeafPoint.
  3. GetCaretRect vertically aligns the rect to the top of the line. To do this, it relies on mIsEndOfLineInsertionPoint being set correctly, which it wasn't previously. Thus, GetCaretRect was using the first character on the next line, resulting in a rect with negative height.
  4. UIA calls TextLeafRange::LineRects, which clips the bounds to the content area. Since the caret rect previously had negative height, it was clipped completely and removed. Thus, UIA previously returned no bounds at all.

All of this is fixed by correctly setting mIsEndOfLineInsertionPoint in this case.

Attachment #9541149 - Attachment description: Bug 2012651: Fix caret coordinates on a line feed at the start of a paragraph preceded by a line of other text. r=morgan! → Bug 2012651: Fix caret coordinates at the start of a paragraph preceded by a line of other text. r=morgan!
Pushed by jteh@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/fca3104d606f https://hg.mozilla.org/integration/autoland/rev/100c4f1c9362 Fix caret coordinates at the start of a paragraph preceded by a line of other text. r=morgan

https://hg.mozilla.org/mozilla-central/rev/100c4f1c9362

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
status-firefox149: fix-optional → fixed
Resolution: --- → FIXED
Target Milestone: --- → 149 Branch

:Jamie, do you want to consider adding an uplift request for beta?
ESR140 is also affected, not sure if it should be uplifted there also?

Flags: needinfo?(jteh)

I'll submit an uplift request for beta. ESR140 doesn't have UIA enabled, and even though comment 4 notes that this was not affected by toggling the UIA pref, I'm still not sure whether this patch will fixthe issue with UIA disabled. We can't properly support Text Cursor Indicator with UIA disabled anyway. So, I'm not going to uplift this to ESR.

status-firefox-esr140: affected → wontfix
Flags: needinfo?(jteh)

This was breaking Text Cursor Indicator when typing into an impacted text box.
This was caused by a cascade of problems:

  1. Previously, we explicitly never set mIsEndOfLineInsertionPoint to true at the start of a paragraph. This is exactly the case we're dealing with here and that behaviour is incorrect. Instead, we now have a much narrower check for the specific exception we're trying to detect: the start of the editor.
  2. GetCaretRect vertically aligns the rect to the top of the line. To do this, it relies on mIsEndOfLineInsertionPoint being set correctly, which it wasn't previously. Thus, GetCaretRect was using the first character on the next line, resulting in a rect with negative height.
  3. UIA calls TextLeafRange::LineRects, which clips the bounds to the content area. Since the caret rect previously had negative height, it was clipped completely and removed. Thus, UIA previously returned no bounds at all.

All of this is fixed by correctly setting mIsEndOfLineInsertionPoint in this case.

Original Revision: https://phabricator.services.mozilla.com/D281126

Attachment #9543733 - Flags: approval-mozilla-beta?

firefox-beta Uplift Approval Request

  • User impact if declined: The Windows Text Cursor Indicator (accessibility feature) will not be positioned correctly when typing at the end of a line in some cases.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: no
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: Code specific to accessibility caret calculation. Covered by multiple automated tests.
  • String changes made/needed: none
  • Is Android affected?: no
Attachment #9543733 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: