Closed Bug 360003 Opened 19 years ago Closed 1 month ago

getRangeExtents reports (0, 0, 0, 0) for list item bullets

Categories

(Firefox :: Disability Access, defect)

Product:
Firefox
Component:
Disability Access
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
140 Branch
Tracking Flags:
Tracking Status
firefox140 --- fixed

People

(Reporter: wwalker, Assigned: Jamie)

References

(Blocks 3 open bugs)

Details

(Keywords: access, Whiteboard: orca:normal)

Attachments

(2 files)

Simple list
63 bytes, text/html
Details
Bug 360003: Add a test for character bounds of list item bullets.
48 bytes, text/x-phabricator-request
Details | Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061025 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061025 Minefield/3.0a1 This is possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=347171, though I chose to file a new bug that was more specific. The problem I'm seeing is that calling getRangeExtents on list item bullets (whether they are unicode bullets or arabic numbers such as "1.") returns (x=0, y=0, width=0, height=0). The impact of this bug is that we are not sure the text is showing on the screen, so we don't present it. Reproducible: Always Steps to Reproduce: 1. Load this content into a page: <html> <ol><li>one</li><li>two</li><li>three</li></ol> </html> 2. Examine the getRangeExtents of the "1. " "2. " "3. " text. It's (0, 0, 0, 0) Actual Results: The getRangeExtents of list bullets is incorrectly reported as (0, 0, 0, 0) Expected Results: The getRangeExtents should report the accurate x, y, width, and height.
Attached file Simple list —
Forgot to add that this also happens in the 07-Nov nightly, but I cannot use that version to file bugs since it suffers from the dreaded CPU throttling problem reported in bug 359210.
I'm not sure how to fix this without refactoring how list bullets are done to be more like :before and :after.
Blocks: newatk
Keywords: access
Actually, I suppose we can hack around this one. We can use the text metrics method we used to use for measuring text, but only when we can't get results the other way.
Will, have you found a workaround for now?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #5) > Will, have you found a workaround for now? No workaround -- we just tend not to present the bullets. :-(
Blocks: texta11y
No longer blocks: newatk
> No workaround -- we just tend not to present the bullets. :-( Or the list item numbers....
Blocks: orca
This is hard to fix so a workaround should be used for now. We might be exposing a text attribute (at least internally), called static="true" for list bullet/number text.
Blocks: lsr
Yes, we'll ask for AT's to work around this for now. After Firefox 3 list bullets are being refactored in layout to use anon content. That will make this way easier.
No longer blocks: lsr
Whiteboard: orca:normal
Severity: normal → S3
See Also: → 1958766
See Also: 1958766 →
Depends on: 1951833
Assignee: nobody → jteh
Status: NEW → ASSIGNED

Strictly speaking, the fix in bug 1951833 isn't a complete fix for list bullets. Now, instead of returning a rect with all 0s, we'll return the rect covering the entire bullet for all characters of the bullet; e.g. both the bullet and the space after it. Bullets do actually get text frames in the layout tree, so we could probably fix this properly, but it'd require significant restructuring of our bullet code, there are tricky edge cases (e.g. CSS alt content), and I'm not sure there's any benefit given that you can't cursor through individual characters of a bullet anyway.

Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b7ecf3a7b8e0 Add a test for character bounds of list item bullets. r=morgan

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

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
status-firefox140: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 140 Branch
QA Whiteboard: [qa-triage-done-c141/b140]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: