Open Bug 307590 Opened 19 years ago Updated 2 years ago

Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

People

(Reporter: mikedbreed, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, testcase)

Attachments

(3 files)

Testcase
353 bytes, text/html
Details
Expanded testcase
882 bytes, text/html
Details
I think this is the way to go
1.25 KB, patch
dbaron
: review-
dbaron
: superreview-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

This bug applies to HTML pages using the DOCTYPE element=<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">.  If a <select> element is styled as
having absolute position and either underlining or strikethrough text styling,
the underline/strikethrough line appears to the right of the drop down list.

Reproducible: Always

Steps to Reproduce:
1. Using Firefox v1.0.6, enter the following URL into the address bar
http://www.jessandmike.net/mozilla/selectboxbug.html and observe
OR
2. Create an HTML document with <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> as the first line
3. Add a form with one select element
4. Add a few options to the select element
5. Add a style for the select element
6. Add position: absolute; to the style for the select element
7. Add text-decoration: underline line-through; to the style for the select element
8. View the page using Firefox v1.0.6

Actual Results:  
The select box was displayed in the upper left hand corner of the page, with
lines sticking out to the right side of the box.

Expected Results:  
The text inside the select element should have been underlined and struckthrough.

If the DOCTYPE element is removed, the page will render correctly.  If the
DOCTYPE element is changed to <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2
Final//EN">, the page also renders correctly.  If the select element is not
absolutely positioned, no styles are applied to the text inside the element at all.
Without the doctype, Mozilla uses 'quirks' mode rendering, where certain rules
are ignored.  Here we're seeing the correct "by the book" rendering.  What's
happening is that the <option> entries are not inheriting the text-decoration
style; if you style them directly you'll get the desired behavior.  This appears
to be correct according to
http://www.w3.org/TR/2005/WD-CSS21-20050613/text.html#propdef-text-decoration

Over to CSS for confirmation by a CSS guru (the prose I linked to is a bit
complicated given my CSS knowledge).  In any case, the layout seems off in the
testcase with those lines to the right.
Assignee: nobody → dbaron
Component: Layout: Form Controls → Style System (CSS)
QA Contact: layout.form-controls → ian
Summary: Underline and strikethrough incorrectly displayed for drop down lists with postion=absolute and HTML 4.0.1 Transitional DOCTYPE → Underline and strikethrough incorrectly displayed for drop down lists with postion=absolute in strict mode
Need testcase attached to the bug.
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Form Controls
Keywords: helpwanted, qawanted
QA Contact: ian → layout.form-controls
Keywords: testcase
Attached file Testcase — 

    
  
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All

    
    

    
  
The key is display:block, not positioning.
Keywords: helpwanted, 
          
            qawanted
Summary: Underline and strikethrough incorrectly displayed for drop down lists with postion=absolute in strict mode → Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode

    
    

    
  


  
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED

        Attachment #207795 -
        Flags: superreview?(dbaron)

        Attachment #207795 -
        Flags: review?(dbaron)

    
    

    
  
I did verify that in the expanded testcase the only behavior that changed is that of the <select>.
Priority: -- → P3
Summary: Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode → [FIX]Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode
Target Milestone: --- → mozilla1.9alpha

    
    

    
  
Comment on attachment 207795 [details] [diff] [review]
I think this is the way to go

I'm not going to let you add more callsites that check NS_FRAME_REPLACED_ELEMENT without clearly defining what NS_FRAME_REPLACED_ELEMENT is supposed to mean.  For this use case, I think it would be inappropriately set for HTML <button> and a whole pile of things constructed in nsCSSFrameConstructor::ConstructXULFrame.

        Attachment #207795 -
        Flags: superreview?(dbaron)

        Attachment #207795 -
        Flags: superreview-

        Attachment #207795 -
        Flags: review?(dbaron)

        Attachment #207795 -
        Flags: review-

    
    

    
  
And I think you need testcases for 'text-decoration' being set on inline containers of these "replaced" elements, don't you?

    
    

    
  
So the real question is what it is about <select> that means we shouldn't strike through it like this....  Should we do it for buttons?  Text inputs?

    
    

    
  
Need clear idea of how this needs to behave...
Assignee: bzbarsky → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Priority: P3 → --
Summary: [FIX]Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode → Underline and strikethrough incorrectly displayed for drop down lists with display:block in strict mode
Target Milestone: mozilla1.9alpha1 → ---

    
  
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: