Closed Bug 1979968 Opened 1 year ago Closed 1 year ago

Introduce insertion point bounds for collapsed range

Categories

(Core :: Disability Access APIs, task)

Product:
Core
Component:
Disability Access APIs
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
144 Branch
Tracking Flags:
Tracking Status
firefox144 --- fixed

People

(Reporter: eeejay, Assigned: eeejay)

References

Details

Attachments

(2 external files)

In mac there is an expectation to have the bounds of a collapsed range be a narrow rectangle where the insertion point would be. The bounds are identical to where the caret would typically be drawn if it were at that offset.

This differs from caret bounds in two ways:

  1. It can be queried when the caret is not at that particular point.
  2. It is not relevant for "special" offsets that only exist for carets, specifically insertion points past the last character, and special end of line insertion points for wrapped text.
Blocks: 1979969

The WritingMode is a single byte bitfield that gives information on the orientation and base direction of the text in the frame.

The absence of the WritingMode in cache can imply the default horizontal LTR direction.

As mentioned in the bug this method does not return bounds for special insertion points.

The bounds are probably correct 90% of the time, the exceptions are transition points in embedded bidi segments,
among other unforseen situations. These edge cases are things we can probably live with for the time being.

This addition also has a few changes:

  1. HyperTextAccessible::TextBounds now returns bounds for identical start and end offsets.
  2. TextLeafRange::Bounds now returns the insertion point for a collapsed range.
  3. The browser caret rect test now uses the insertion point rect to compare against the caret rect.

Depends on D259133

  1. It is not relevant for "special" offsets that only exist for carets, specifically insertion points past the last character, and special end of line insertion points for wrapped text.

Per discussion on Matrix, Mac still needs these, even though we can only get them at the caret. UIA is the same. I'd prefer that this special case of retrieving caret bounds is unified in cross-platform code rather than special casing in two places.

Pushed by chorotan@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/211b124048fc https://hg.mozilla.org/integration/autoland/rev/1df438e76bed Revert "Bug 1979968: apply code formatting via Lando" for causing ba failures on browser_caret_rect.js

Backed out causing ba failures on browser_caret_rect.js

Backout link

Push with failures

Failure log

Flags: needinfo?(eitan)
Pushed by ctuns@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/66586f249918 https://hg.mozilla.org/integration/autoland/rev/73633462e007 Revert "Bug 1979968: apply code formatting via Lando" for causing mochitest failures in browser_caret_rect.js

Backed out for causing mochitest failures

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | accessible/tests/browser/bounds/browser_caret_rect.js | 7: Collapsed range extents at caret position should be identical caret rect - [236,189,1] deepEqual [236,188,1] -

https://hg.mozilla.org/mozilla-central/rev/39a7f4fc6dc9
https://hg.mozilla.org/mozilla-central/rev/615582fb0d81
https://hg.mozilla.org/mozilla-central/rev/3324cce6026f

Status: NEW → RESOLVED
Closed: 1 year ago
status-firefox144: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 144 Branch
No longer blocks: 1979969
Duplicate of this bug: 1979969
Blocks: 1981794
QA Whiteboard: [qa-triage-done-c145/b144]
Flags: needinfo?(eitan)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: