1981794 - The location of the Text Cursor Indicator is not correctly positioned in blank text boxes all around the browser

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Daniel Bodea [:danibodea]]

Note

• When the Text Cursor Indicator is enabled in Windows and UIA is enabled in Firefox, when the user focuses a blank text box throughtout the browser, the TCI is not displayed in the position of the actual cursor.
• Blank boxes cause a bunch of problems in different areas (all search boxes in “about” pages, in the profile name text box from the Profile Manager, in the Bookmarks/History/Downloads Manager search boxes, Report Broken Site window, etc. In most cases, the actual text cursor is displayed right after an icon or image, while the Text Cursor Indicator is displayed right at the left edge of the text box. In other cases where the text box is tall, half the TCI is displayed at the top left edge of the box, and the other half at the bottom.
• This is only cosmetic, not a severe issue (S4).

Found in

• Nightly v143.0a1

Affected versions

• Nightly v143.0a1

Tested platforms

• Affected platforms: Windows 10, Windows 11
• Unaffected platforms: Mac, Linux

Steps to reproduce

1. Enable Text Cursor Indicator in Windows
2. Enable UIA in Firefox (default in Nightly 143)
3. Load Preferences and focus the Search box

Expected result

• The Text Cursor Indicator is displayed in the same position as the actual Text Cursor

Actual result

• The Text Cursor Indicator is displayed in a different position than the actual Text Cursor.
• The Text Cursor Indicator is displayed right at the left edge of the text box.

Regression range

• This is not a regression, but an issue since the implementation of the UI Automation feature.

Additional notes

• This issue only occurs in blang text boxes; if the user starts typing, the TCI will correctly display in the same position as the actual Text Cursor.

Comment 1

[Daniel Bodea [:danibodea]]

Attachment: TCI - wrong position in preferences search box.png

Comment 2

[Daniel Bodea [:danibodea]]

Attachment: TCI - report broken site - description text box.png

Comment 3

[James Teh [:Jamie]]

Thanks for testing and reporting. To clarify, does this only occur when UIA is enabled? That is, is the indicator displayed in the correct position in blank text boxes when UIA is disabled?

Comment 4

[Daniel Bodea [:danibodea]]

This only occurs with UIA enabled, because the Text Cursor Indicator is not displayed at all in blank text boxes around the browser when UIA is disabled. Please feel free to address this report however you see fit.

Comment 5

[James Teh [:Jamie]]

Attachment: Bug 1981794: Always return insertion point bounds for a collapsed UIA text range.

Previously, UIA had its own code to use the caret rect for the end of line insertion point or a line feed at the end of a textarea.
However, this didn't account for an empty text box.
To fix this, now that we have unified code in TextLeafRange to use the insertion point in all cases where it is necessary, use that instead of UIA specific code.
This involved moving the call to TextLeafPoint::InsertionPointBounds from TextLeafRange::Bounds to TextLeafRange::WalkLineRects, since UIA uses TextLeafRange::LineRects, not TextLeafRange::Bounds.

Comment 6

[James Teh [:Jamie]]

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=150295

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/33be2d8c1cfa
https://hg.mozilla.org/integration/autoland/rev/e31d56a4a7ba
Always return insertion point bounds for a collapsed UIA text range. r=eeejay

Comment 8

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/e31d56a4a7ba

Comment 9

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:Jamie, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox143 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[James Teh [:Jamie]]

Morgan, would you mind testing this and bug 1981821 with latest Nightly? This is a little time sensitive, as I need to get this uplifted ASAP if we're to get it into the final beta for 143 on 5 September. Thanks.

Comment 11

[Morgan Reschenberg [:morgan]]

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

Morgan, would you mind testing this and bug 1981821 with latest Nightly? This is a little time sensitive, as I need to get this uplifted ASAP if we're to get it into the final beta for 143 on 5 September. Thanks.

Hello! Sorry for the lag here -- this is fixed in 2025-09-04's nightly build. I tested the input field in about:preferences and the text cursor is placed appropriately within the input when focus lands there, it also moves correctly when you input text.

Comment 12

[James Teh [:Jamie]]

Thanks. I'm elevating this to s3 because I'm closing bug 1981821 as a duplicate, which is s3.

Comment 14

[James Teh [:Jamie]]

Attachment: Bug 1981794: Always return insertion point bounds for a collapsed UIA text range. r=eeejay

Previously, UIA had its own code to use the caret rect for the end of line insertion point or a line feed at the end of a textarea.
However, this didn't account for an empty text box.
To fix this, now that we have unified code in TextLeafRange to use the insertion point in all cases where it is necessary, use that instead of UIA specific code.
This involved moving the call to TextLeafPoint::InsertionPointBounds from TextLeafRange::Bounds to TextLeafRange::WalkLineRects, since UIA uses TextLeafRange::LineRects, not TextLeafRange::Bounds.

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

Comment 15

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Windows Text Cursor Indicator will appear in the wrong place in an empty text box.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: not applicable
• Risk associated with taking this patch: low
• Explanation of risk level: Isolated to a specific area of accessibility code which is well covered by multiple layers of testing.
• String changes made/needed: none
• Is Android affected?: no

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/6d949111ddf7
https://hg.mozilla.org/releases/mozilla-beta/rev/b66f10917dcc

Comment 17

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/2e5c04bedaee
https://hg.mozilla.org/releases/mozilla-beta/rev/4fc2d2fb5e43

Comment 18

[Atila Butkovits]

Backed out from beta for causing bustages.

Backout link: https://hg-edge.mozilla.org/releases/mozilla-beta/rev/4fc2d2fb5e43

Push with failures: https://treeherder.mozilla.org/jobs?repo=mozilla-beta&selectedTaskRun=eDKnPG7SQ_-W2oiFah7q1w.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=b66f10917dcc807b586e5c28dbd967764d57abba

Failure log: https://treeherder.mozilla.org/logviewer?job_id=525763751&repo=mozilla-beta&task=eDKnPG7SQ_-W2oiFah7q1w.0&lineNumber=15761

Comment 19

[James Teh [:Jamie]]

I neglected to realise this depends on patches (bug 1979968) which only landed in 144. Those patches add quite a bit of code. I don't think the benefit here is worth the additional risk, so I'm abandoning this uplift request. Sorry for the churn.