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
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.
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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: