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)
Tracking
()
NEW
People
(Reporter: wwalker, Unassigned)
References
(Blocks 3 open bugs)
Details
(Keywords: access, Whiteboard: orca:normal)
Attachments
(1 file)
|
63 bytes,
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.
|
Reporter | |
Comment 1•18 years ago
|
||
|
|
Reporter | |
Comment 2•18 years ago
|
||
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.
|
||
Comment 3•18 years ago
|
||
I'm not sure how to fix this without refactoring how list bullets are done to be more like :before and :after.
|
|
||
Comment 4•18 years ago
|
||
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.
|
|
||
Comment 5•18 years ago
|
||
Will, have you found a workaround for now?
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
Reporter | |
Comment 6•18 years ago
|
||
(In reply to comment #5)
> Will, have you found a workaround for now?
No workaround -- we just tend not to present the bullets. :-(
|
|
||
Updated•18 years ago
|
|
||
Comment 7•18 years ago
|
||
> No workaround -- we just tend not to present the bullets. :-(
Or the list item numbers....
|
|
||
Comment 8•18 years ago
|
||
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.
|
|
||
Comment 9•18 years ago
|
||
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.
|
|
||
Updated•17 years ago
|
Whiteboard: orca:normal
|
||
Updated•15 years ago
|
Blocks: bulleta11y
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•