Open Bug 360003 Opened 18 years ago Updated 2 years 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

()

People

(Reporter: wwalker, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: access, Whiteboard: orca:normal)

Attachments

(1 file)

Simple list
(deleted), text/html
Details
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 (deleted) —
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: