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.
Need testcase attached to the bug.
The key is display:block, not positioning.
Created attachment 207795 [details] [diff] [review] I think this is the way to go
I did verify that in the expanded testcase the only behavior that changed is that of the <select>.
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.
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...