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

NEW
Unassigned

Status

()

Core
Layout: Form Controls
12 years ago
3 years ago

People

(Reporter: Michael Breed, Unassigned)

Tracking

({helpwanted, testcase})

Trunk
helpwanted, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
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.

Comment 1

12 years ago
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

Updated

12 years ago
Keywords: testcase

Comment 3

12 years ago
Created attachment 207015 [details]
Testcase

Updated

12 years ago
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
Created attachment 207794 [details]
Expanded testcase
Created attachment 207795 [details] [diff] [review]
I think this is the way to go
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 → ---
You need to log in before you can comment on or make changes to this bug.