text-decoration: line-through should not be painted on a <select> child

RESOLVED FIXED in mozilla18

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Deleted User, Assigned: bz)

Tracking

Trunk
mozilla18
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120821170930

Steps to reproduce:

Outlined in this StackOverflow post: 
http://stackoverflow.com/questions/12191753/css-overriding-an-inherited-text-decorationline-through#comment16324982_12191753  

Demo at this fiddle: http://jsfiddle.net/Y7ZVp/


Actual results:

Line through remains on child element with parent text-decoration: line-through even if child has text-decoration: none


Expected results:

The child should return to normal text.
Created attachment 656813 [details]
Reporter's Testcase
I see no Difference to other Browsers.

Updated

6 years ago
Component: Untriaged → Style System (CSS)
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All

Comment 3

6 years ago
Reproducible on the 09/04 Firefox 18 Nightly on Mac and Linux (didn't try on Windows).

As XtC4UaLL says, the same issue reproduces in Safari, Chrome, and Opera.
Status: UNCONFIRMED → NEW
Ever confirmed: true
And that's because the spec says to do this.

Marking invalid, but if someone has the time to find the oldest report on this and mark duplicate, feel free!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Whiteboard: DUPEME
Though wait.  I don't see the strike-through going through the select on Chrome on Mac.  Does it do so on Windows?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Resummarizing to cover the actual issue, not the incorrect initial description.

David, I think we've considered not propagating text-decoration to "replaced" elements in the past...  Thoughts?
Summary: Inheritance of text-decoration: line-through is unable to be overridden → Inheritance of text-decoration: line-through should not propagate to a <select> child
Summary: Inheritance of text-decoration: line-through should not propagate to a <select> child → text-decoration: line-through should not be painted on a <select> child
(In reply to Boris Zbarsky (:bz) from comment #6)
> Resummarizing to cover the actual issue, not the incorrect initial
> description.
> 
> David, I think we've considered not propagating text-decoration to
> "replaced" elements in the past...  Thoughts?

In some cases we've changed their default display (or that of an anonymous child) from 'inline' to 'inline-block' to cause this (https://hg.mozilla.org/mozilla-central/rev/3a73e65c935e ; https://hg.mozilla.org/mozilla-central/rev/c9dff8b867f0).  If we need to do it without that corresponding change in 'display' it might be reasonable as well.
(And I can't think of anything left other than select, after those two changes, actually.)
OK, well UA behavior for this is as follows:

Default display:
  WebKit: No decorations
  Presto: No decorations
  Trident: No decorations
  Gecko: Decorations

display:inline:
  WebKit: Decorations on combobox, not listbox
  Presto: No decorations
  Trident: Decorations in standards mode and IE8 mode.  
           No decorations in IE7 and quirks modes.
  Gecko: Decorations

display:inline-block:
  WebKit: No decorations
  Presto: No decorations
  Trident: No decorations
  Gecko: No decorations

So just flipping the default display will give us the IE8/IE9 behavior and at least match WebKit on combobox.  Sounds like we should do that.
Assignee: nobody → bzbarsky
Whiteboard: DUPEME → [need review]
Version: 15 Branch → Trunk
Created attachment 659115 [details] [diff] [review]
Don't propagate text-decoration to <select> by default.
Attachment #659115 - Flags: review?(dbaron)
Attachment #659115 - Flags: review?(dbaron) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d12416121a6
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla18
And backed out, because it breaks the font-inflation tests for <select>.  David, is that a bug in the patch, or in the tests?
Flags: in-testsuite+
Whiteboard: [leave open]
Target Milestone: mozilla18 → ---
Probably the patch, since those tests were written based on desired behavior.

Try adding the single line content->IsHTML(nsGkAtoms::select) to the function IsFontSizeInflationContainer in nsFrame.cpp (next to option and optgroup).
Yeah, that works.  I'm going to reland with that change.
https://hg.mozilla.org/integration/mozilla-inbound/rev/175c768112a4
Flags: in-testsuite+
Whiteboard: [leave open]
Target Milestone: --- → mozilla18
https://hg.mozilla.org/mozilla-central/rev/175c768112a4
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 803995
No longer depends on: 803995
You need to log in before you can comment on or make changes to this bug.