79107 - Styles assigned to OPTION elements aren't used for pull-down SELECT lists (comboboxes)

Status: REOPENED

(Core :: Layout: Form Controls, defect)

Description

[Skewer]

Procedure: Go to the URL (I might make a testcase later) and go down to the
color listbox (also happens on the gender listbox). Select one of the items that
has a style applied to it.

Expected: When the listbox is collapsed, the style for the OPTION element should
still be visible.

Actual: When the listbox is collapsed, the style for the SELECT is used and the
style for the OPTION is ignored. I can't find anything in the CSS spec about
this, but in theory the style for the OPTION should always take priority. Can
anyone confirm W3C's position on this one way or the other? I will also note
that IE5.5 behaves as expected.

Build: 20010505 Win98

Comment 1

[Skewer]

Adding a simplified testcase, URL no longer needed. Adding appropriate keyword.

Comment 2

[Skewer]

Attachment: Options with CSS in a pull-down listbox testcase

Comment 3

[Hixie (not reading bugmail)]

This may get fixed by the XBL form controls.

Comment 4

[Jacob Kjome]

There seems to be another component to this bug:

In build 2001060804 on Win2k (SP2), there seems to be some space between 
options. Let's assume that all the options are colored yellow.  What you should 
see when you drop the list down is a solid yellow background in the area behind 
all the options. However, between certain options, there is a break in the 
background letting the parent element's (select) background shine through.

I'm attaching a testcase for that shortly...

Jake

Comment 5

[Jacob Kjome]

Attachment: testcase showing <select> background shining through between some <option> elements

Comment 6

[Skewer]

I'm seeing the described behavior at or below 90% zoom in 2001060804 Win98. You
may want to start another bug for this, it's a separate issue.

Comment 7

[Jacob Kjome]

Reported bug 85051 for behavior I recently commented on in this bug.

Jake

Comment 8

[Jesse Ruderman]

*** Bug 90090 has been marked as a duplicate of this bug. ***

Comment 9

[Jesse Ruderman]

See also bug 56451.

Comment 10

[Skewer]

*** Bug 56451 has been marked as a duplicate of this bug. ***

Comment 11

[Greg K.]

Reconfirmed using FizzillaCFM/2002070913. Setting All/All.

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 180728 has been marked as a duplicate of this bug. ***

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** Bug 153307 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 165093 has been marked as a duplicate of this bug. ***

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 186379 has been marked as a duplicate of this bug. ***

Comment 16

[Boris Zbarsky [:bzbarsky]]

I think jkeiser wanted this, based on one of the dups.

Comment 17

[Boris Zbarsky [:bzbarsky]]

*** Bug 193318 has been marked as a duplicate of this bug. ***

Comment 18

[Thad Hoffman]

Just confirming still exists in 1.3b

(I'm running through my list of bugs against 1.3b and making notes)

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 201194 has been marked as a duplicate of this bug. ***

Comment 20

[Boris Zbarsky [:bzbarsky]]

So... When the <select> is collapsed, you are seeing the <select> not the
<option>.  This becomes pretty obvious if you drop the list down -- then you see
the <select> _and_ the <option>

As in, I don't know whether per spec this is a bug at all.

Not to say that we may not want to "fix" it in the name of compat.

Comment 21

[Jesse Ruderman]

*** Bug 213305 has been marked as a duplicate of this bug. ***

Comment 22

[Alfonso Martinez]

*** Bug 232747 has been marked as a duplicate of this bug. ***

Comment 23

[José Jeria]

*** Bug 235820 has been marked as a duplicate of this bug. ***

Comment 24

[Jesiah S]

*** Bug 238981 has been marked as a duplicate of this bug. ***

Comment 25

[Bill Mason]

*** Bug 246656 has been marked as a duplicate of this bug. ***

Comment 26

[Telmo Amaral]

*** Bug 248628 has been marked as a duplicate of this bug. ***

Comment 27

[Boris Zbarsky [:bzbarsky]]

*** Bug 255040 has been marked as a duplicate of this bug. ***

Comment 28

[Telmo Amaral]

Bug 255040 (reported by [e-mail] and marked as a duplicate of this one)
brings attention to the fact that (at least to some extent) it is possible to
work around the problem using JavaScript. This was useful for me, so here’s a
small example to illustrate how it can be done, keeping the use of a style-sheet:
http://paginas.fe.up.pt/~tga/issue_20040625/
Relevant files in the directory are index.htm, main.css and javascripts.js.
Please note that a style must be defined for the default colour as well;
otherwise, any default-coloured option would adopt the colour of the last
selected option. Also, for some reason, using this work around, the border style
of the select element seems to get stuck at “inset”; there’s no way to override
it – maybe this is another bug.

Comment 29

[osavill]

> Also, for some reason, using this work around, the border style
> of the select element seems to get stuck at “inset”; there’s no way to override
> it – maybe this is another bug.

It is another bug and it has been reported :-) Sadly, the 4 pixel bevel border
appears now fixed and this appears to be a feature not a bug "in the name of
compat" :-( 

Comment 30

[Telmo Amaral]

Yes, I guess you mean Bug 187691. If indeed there's no specification on how to
handle the border style, then it seems acceptable to simply ignore the style and
set the border to a default. What I find confusing is that the border is set to
_different defaults in different situations_: when no style is set or only the
border style is (tentatively) set, the border defaults to solid; when both the
border and the background-color styles are (tentatively) set, the border
defaults to inset (and the background is set as expected). This test-case
illustrates that behaviour:
http://paginas.fe.up.pt/~tga/issue_20040817/

By the way, the JavaScript work-around in my previous post is not fully
successful: it works if one uses the mouse; it doesn't work if you tab to the
control and then use the arrow keys to move through the options. This seems to
indicate that the onchange script runs only when the change is triggered by the
mouse... This is probably another issue, probably already reported . Will try to
figure out some other way to achieve coloured selects, as I really need
something of the sort, preferably working with Mozilla.

Comment 31

[Jesiah S]

Telmo, onchange only fires with the mouse, hitting enter key, or leaving the
SELECT. This is because some site use the onchange to autmatically send the user
to a website.  If onchange fired with a simple down arrow users could not
navigate these websites see www.comics.com.

Comment 32

[Telmo Amaral]

Thanks Jesiah, that makes all sense.

Comment 33

[Boris Zbarsky [:bzbarsky]]

*** Bug 265083 has been marked as a duplicate of this bug. ***

Comment 34

[Jesse Ruderman]

*** Bug 271160 has been marked as a duplicate of this bug. ***

Comment 35

[Frank Wein [:mcsmurf]]

*** Bug 278994 has been marked as a duplicate of this bug. ***

Comment 36

[Justin Wood (:Callek)]

re: c#20 for what its worth IE does at least paint the <option> background
in-place of the <select> background when it is specified.

for another testcase see the URL (you may need to copy/paste that into the
url-bar of your browser)

In this testcase when Foo is selected and select is "closed" the background
should shine green not red, and when bar is selected, background should shine
red still

Comment 37

[Andrés G. Aragoneses]

Hello. I was going to file a new bug, but I think I have found this one, which
could correct the behaviour I have found when is fixed. I will add a new testcase.

BTW: the URL of this bug has an errata (transparant, instead of transparent).

Comment 38

[Andrés G. Aragoneses]

Attachment: Testcase which shows that FF doesn't apply a color to an option element until the combo drops down

Comment 39

[Samuel Sieb]

Comment on attachment 37774 [details]
testcase showing <select> background shining through between some <option> elements

This testcase seems to be obsolete now.  There is no space between options on
latest Mozilla trunk on Linux.	I even tried with various font scalings.

Comment 40

[Andrés G. Aragoneses]

Samuel, I think you are correct about that attachment. [WFM: Firefox 1.0.4 in
SUSE Linux 9.3 (Gecko/20050511).]

Comment 41

[Jacob Kjome]

Samuel,

Space between options was a side issue which ended up being reported as another
bug.  It has been fixed for a long time now.  So you are missing the point if
that by working for you, you think that this bug is WFM.

Also, the testcase in the URL field misses the point.  The idea is that if the
background color either hasn't been set or has been set explicitly to
transparent, then the color of the first option ought to show through (whether
the spec defines this or not, that's the core argument here).

So, this would be more appropriate...

data:text/html,<select style="background-color:transparent;"><option
style="background-color:green;">foo</option><option
style="background-color:transparent;">bar</option></select>


There are a couple goofy things going on here:

1.  The green color of the first option isn't showing through the unselected box
(for instance, on initial page load before any action is taken on the box), even
though the select's color is transparent.

2.  When the select box is dropped down, the non-explicitly colored option is
gray.  That's clearly a bug.  And when one removes the background-color setting
on the select, the formerly gray option becomes white, as it should have been
when the select was set to transparent.

So, this bug is nowhere near addressed.  And even if it is decided that the
specs don't define behavior clearly enough here to make it worth making a change
in select/option coloring behavior, #2 above still needs to be addressed because
of the inconsistent behavior in coloring of option elements depending on the the
coloring of the select element.


Jake

Comment 42

[Adam Guthrie]

*** Bug 300109 has been marked as a duplicate of this bug. ***

Comment 43

[Hawk]

I am having a similar issue with this bug, but in a different context.  I can't submit my example because bugzilla crashes.  It's pretty small, so let me include it here:

<body>

<style>
select{background-color:#DF7;width:100%;}
.op{background-color:#FFF}
</style>

<select id="page" name="page" style="width:100px">
<option value=""></option>
<option value="names" class="op">Names</option>
<option value="phone" class="op">Phone</option>
<option value="logout">OK</option>
</select>

<select id="page" name="page" style="width:100px">
<option value=""></option>
<option value="names" class="op">Names</option>
<option value="phone" class="op">Phone</option>
<option value="logout">THIS IS TOO LONG</option>
</select>

 </body>

Comment 44

[Jacob Kjome]

Just a note:  point #2 in comment #41 no longer seems to be an issue.  Point #1 is still an issue.

Jake

Comment 45

[Gérard Talbot]

*** Bug 354850 has been marked as a duplicate of this bug. ***

Comment 46

[Gérard Talbot]

(In reply to comment #20)
> I don't know whether per spec this is a bug at all.
> Not to say that we may not want to "fix" it in the name of compat.

I read very carefully [HTML4-17.6] and [CSS1-5.3.7] and I fail to see where or how the spec indicate that, by default, styles assigned to OPTION elements should "bubble up" or be transferred to collapsed select lists. 

DOM inspector show that the default background-color of select is background-color: rgb(255, 255, 255);
and not 
background-color: transparent;

On the Windows platform, colors affecting selected items are theme-predefined and also user-customizable via:

Start/Control Panel/Display/Appearance tab/Advanced button/Item:/Selected items/

I.e.: Color 1 will choose the background color of selected items. 
Also, os color scheme will affect background-color and text color of selected items.

For web authors, CSS 3 selectors module offer via the dynamic pseudo-class ::checked property capability to style the option element.
"The :checked pseudo-class initially applies to such elements that have the HTML4 selected and checked attributes"
http://www.w3.org/TR/css3-selectors/#checked

I'm removing html4 and css1 keywords and adding compat keyword.

Comment 47

[Gérard Talbot]

Another testcase for this bug:

http://www.gtalbot.org/BugzillaSection/Bug79107.html

Expected results: transparent

Actual results in Seamonkey 1.5.a rv:1.9a1 build 2006093009 and in Firefox 1.5.0.7 rv:1.8.0.7 build 20060909: rgb(255, 255, 255)

Note that Opera 9.02 succeeds and gets the expected results; MSIE 7 RC1 build 5700.6 fails and returns #ffffff

Comment 48

[Ric Hardacre]

(In reply to comment #46)
> (In reply to comment #20)
> > I don't know whether per spec this is a bug at all.
> > Not to say that we may not want to "fix" it in the name of compat.
> 
> I read very carefully [HTML4-17.6] and [CSS1-5.3.7] and I fail to see where or
> how the spec indicate that, by default, styles assigned to OPTION elements
> should "bubble up" or be transferred to collapsed select lists. 
> 

That's one interpretation, the one that the bug reporters here are assuming is that the SELECT element contains OPTION elements. The selected item *is* an OPTION element, and therefore should look exactly the same when selected in the SELECT as it does in the drop-down-list.

Your interpretation appears to suggest, instead, that the SELECT element contains the Text and Value copied from the selected OPTION, much like when you select a windows combobox or intellisense input to copy the selected text into the input.


I, too, prefer the first definition of behaviour and would like to see styles applied to OPTION elements apply when the same option is selected in a single-line SELECT

Comment 49

[Gérard Talbot]

> That's one interpretation, the one that the bug reporters here are assuming is
> that the SELECT element contains OPTION elements. The selected item *is* an
> OPTION element, and therefore should look exactly the same when selected in the
> SELECT as it does in the drop-down-list.

The current Mozilla behavior is not in violation of any known or implicit HTML 4.01 guidelines/recommendation whatsoever or any CSS1 guidelines/recommendations. So, this is not an HTML 4 issue at all and it is not a CSS1 issue either. It's just a compatibility issue with what other browsers do (behavior) and/or with what is the default background-color (computed style) for select in other browsers. That's it.
 
> Your interpretation appears to suggest, 

Please do not interpret any further than what I am saying. There is nothing in the HTML 4 and CSS1 specifications that say or indicate how a <select> should behave once a item is selected or that says that default background-color of a select should be transparent.

Comment 50

[Steve England [:stevee]]

*** Bug 363107 has been marked as a duplicate of this bug. ***

Comment 52

[Nils Hammar]

So is anybody working on this bug?

Considering the number of duplicates (22 right now) that has been detected it should be fixed just to avoid more unnecessary bug reports.

Comment 53

[Ben Isaacs]

Nils, do you realise that this bug has been open for the best part of 6 and a half years now...? :'(

Comment 54

[osavill]

Read the entire thread. It's got itself into a stalemate as no one can decide exactly what the spec is / means. In this case I think the aesthetics of the situation should prevail, oh and also 'cos every other browser on the planet applies the style in a sensible manner.

Comment 55

[Ben Isaacs]

To reply to Gérard Talbot's comment from October 2006;

The current behaviour is not in violation of any specification, but only in the sense of "if they didn't put it in the spec then what we do is not wrong" - an engineering principle beloved by many programmers because it gets them out of trying to do "the right thing". 

The current implementation, although "not wrong", is certainly unsatisfactory by the standards of enough people that this bug has been reported 22 times and remains open after nearly 6.5 years.

The issues at hand:
1. Whether or not either the current or proposed behaviour implements all relevant spec
2. Whether or not either the current or proposed behaviour violates any relevant spec
3. What other browsers do (cross-compat)
4. Given the freedom to do what we want within spec, what users or developers expect
5. How much effort is involved in offering such enhanced functionality

Gérard has established - in no uncertain terms - that the current behaviour satisfies both 1 and 2. 

The proposed behaviour (of OPTION styles 'bubbling up' to SELECT style on option change) may or may not adhere to 1 and 2. It is not entirely clear from this thread. But I suspect that it does not, as it would break all kinds of things. Thus, that is not the correct fix.

Other browsers appear to treat SELECT as a container with an OPTION in it, and I suspect that this is the 'expected' behaviour from a user's natural point of view as well: it is common sense that SELECTs contain OPTIONs, and 1 OPTION is visible at all times. That's implicit (not explicit) in the HTML spec. To me and to others in this thread, 3 and 4 suggest we need change.

As for 5: if memory serves - as visual grep is failing to do - the part of the code which was responsible for this bug is or was once due for a rewrite, and that's why this was left dangling. It's been so many years that I could be imagining this though.

The astute follower of this thread will notice that some of the test cases now work much more closely as you'd expect they should (some of the early comments are now irrelevant). There are still cases where Gecko does not do what you would reasonably expect, though, such as this one:

<select>
<option style="font-size: 10px">test</option>
<option style="font-size: 20px">test</option>
<option style="font-size: 30px">test</option>
</select>

It is CLEARLY a bug that SOME of the Option styles are inherited by the SELECT when others are not.

I suspect that another 2, possibly 3 rounds of argument - and as many years - are probably required before this bug is resolved.

Alternatively, HTML5 may make this behaviour explicit. We shall see... see you all again in 2011.

Comment 56

[Gérard Talbot]

John Keiser is assigned to this bug.

Nils, if you want a workaround, you can set dynamically the background-color of the select to the background-color of the selected option with javascript. This works for me and has been working for Telmo Amaral ... with just 2 lines of code:

objSelect.style.backgroundColor = objSelect.options[objSelect.selectedIndex].style.backgroundColor;
objSelect.style.color = objSelect.options[objSelect.selectedIndex].style.color;

Example:
http://www.gtalbot.org/DHTMLSection/AdvancedCSSButtons.html

"The only person who has any obligation to fix the bugs you want fixed is you."
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

The key in this bug is to support background-color: transparent for the select like hoju and others said, so that when the select is collapsed, the background-color of the selected option shines through. Opera 9.25, Opera 9.50, Konqueror 3.5.8 implement this and pass this testcase:

http://www.gtalbot.org/BugzillaSection/Bug79107.html

Adding [parity-opera]

Comment 57

[Gérard Talbot]

> 3. What other browsers do (cross-compat)

IE 6, IE 7 have a bug (reported for over a year now) with this:
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/BackgroundColorSelect.html
If the select is green, then it should not says that it's white (#fffff) but transparent.
Opera 9.25, Opera 9.50, Konqueror 3.5.8 behaviors, respective implementations is what, I believe, Mozilla should follow, should implement.

> 4. Given the freedom to do what we want within spec, what users or developers
expect

Implement background-color: transparent for the select (in particular when it is collapsed) as explained in comment #41 and #44. I assume we all agree, we all converge on this. I'll resummarize and point to a new URL, unless I hear loud objections. The current URL is not even working and not correct either.

> (...) remains open after nearly 6.5 years.
> 5. How much effort is involved in offering such enhanced functionality

"The only person who has any obligation to fix the bugs you want fixed is you."
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Ben, submit a patch and this bug will get resolved+fixed soon.

Comment 58

[Ben Isaacs]

(In reply to comment #57)
> > 3. What other browsers do (cross-compat)
> 
> IE 6, IE 7 have a bug (reported for over a year now) with this:
> http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/BackgroundColorSelect.html
> If the select is green, then it should not says that it's white (#fffff) but
> transparent.
> Opera 9.25, Opera 9.50, Konqueror 3.5.8 behaviors, respective implementations
> is what, I believe, Mozilla should follow, should implement.

Perhaps I'm being particularly dense, but I do not understand:
A. why transparent is more correct than white
B. how this is relevant to (what I consider to be) the focus/spirit of this bug report

To explain further:
A. _If_ SELECT is a box (in the box-model sense), and for display purposes it contains a single OPTION, then the parent (SELECT) style is irrelevant when the displayed child has explicit styling that overrides it, because it is in front. Thus, when 'green' is selected, you should see a green background on the OPTION which is itself within the SELECT (who's background is now obscured.) The computed style of the select box itself would remain at whatever it was set before, from the point of view of CSS and JS. In this case, why should 'transparent' be prefered to 'white' for the SELECT when it is hidden under the selected OPTION anyway?

B. The main point of the bug in my eyes is that when you select an option, only the inner text of the option is copied to the select for display; but one would expect the entire styled box content to be copied for display. Worse, the SELECT appears to be prepared to contain the OPTION in a fully styled way, for example it is the correct size to contain the largest OPTION available, even though this never happens.

Therfore, I do not believe that the solution to the bug can possibly be as narrow in scope as you say it is.

> > 4. Given the freedom to do what we want within spec, what users or developers
> expect
> 
> Implement background-color: transparent for the select (in particular when it
> is collapsed) as explained in comment #41 and #44. I assume we all agree, we
> all converge on this. I'll resummarize and point to a new URL, unless I hear
> loud objections. The current URL is not even working and not correct either.
 
Please do.

> > (...) remains open after nearly 6.5 years.
> > 5. How much effort is involved in offering such enhanced functionality
> 
> "The only person who has any obligation to fix the bugs you want fixed is you."
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> Ben, submit a patch and this bug will get resolved+fixed soon.

Whilst I appreciate the spirit of this (and I am certainly not one to _demand_ something for nothing :) - I, unfortunately, do not have the required skills to implement this myself. I contribute to other open source projects, but my C skills are pretty weak. 

My interest lies in trying to help with the clarity of this bug. I suspect that it has been open for so long because it is poorly understood, and I still think that it is poorly understood despite what you said in your last comment.

Comment 59

[Nils Hammar]

(In reply to comment #56)
> John Keiser is assigned to this bug.
> 
> Nils, if you want a workaround, you can set dynamically the background-color of
> the select to the background-color of the selected option with javascript. This
> works for me and has been working for Telmo Amaral ... with just 2 lines of
> code:

It's no problem doing it in JavaScript by itself, but the general feeling is that it is unnecessary work to be able to be consistent over different browsers to obtain the expected effect.

And - yes I did check the comments, and the opinion I have is that there will be more bug reports against this behavior in the future, so only that would be a reason to solve it.

Comment 62

[Jason Oster (:Parasyte)]

Attachment: Workaround

Here's a JavaScript work-around that attempts to apply all styles for the selected option element to its parent select element. The script is unobtrusive; using it requires just adding a simple:

<script type="text/javascript" src="listboxcolors.js"></script>

... to your HTML. The script is based (in part) on some examples provided earlier.

Also, developing this script lead me to a new bug: Bug 494507

Comment 67

[Jonathan Watt [:jwatt]]

Chrome, Safari and Opera do not implement this. In fact they don't seem to support styling of the options even when the dropdown is expanded. Seems like we should just wontfix this.

Comment 68

[support]

@Jonathan Watt: 

Chrome does show colored option elements in Selectboxes ... no idea where you got your informations.

Comment 69

[Jonathan Watt [:jwatt]]

I tested the attached testcases...on Mac. And in this case I apparently assumed that Chrome would be consistant about this across platforms. It is not. The testcases seem to work in Chrome on Windows.

Comment 71

[support]

and in chrome on linux

Comment 73

[Mike McNally]

This seems to work in Firefox 64.0.2 on Windows, but not 64.0 on Linux. Works in Edge and Chrome in Windows, and Chrome in Linux. Test codepen: https://codepen.io/Pointy/pen/YBqjxq

Comment 74

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 29 duplicates and 18 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 75

[Emilio Cobos Álvarez (:emilio)]

We support it on windows and on all non-android platforms with dom.forms.select.customstyling=true, but it unlikely to become the default on macOS at least, and probably Linux.

Comment 76

[support]

is there any good reason, why it a) was disabled ( because it was working on Linux long ago oob) and b) is not enabled by default at all?

Reference: https://www.w3schools.com/tags/tag_option.asp supports https://www.w3schools.com/tags/ref_standardattributes.asp here STYLE.
So it's in the w3c standards.

Comment 77

[Emilio Cobos Álvarez (:emilio)]

It never worked properly on Linux after e10s until relatively recently (see bugs that block bug 1406865). On macOS it was disabled in bug 1703866, see there for context.

Comment 78

[support]

Forgive me, what is/was "e10s"?

That bug is 5 years old and needs retesting, so I run a testcase for coloring the options background, which worked as expected on Fedora 35 FF 105, after I enabled it in the prefs.

Is there testsite to run a full test on it?

Comment 79

[Emilio Cobos Álvarez (:emilio)]

Presumably that needinfo was for me. A bit hilarious that there's an Emilio Alvarez with a very similar name to me.

e10s is electrolysis, the Firefox multi-process architecture that was worked on a while ago and reworked the select popup (to draw it in the parent process).

Locally, on Arch, there are two subtests of browser/base/content/test/forms/browser_selectpopup_colors.js which fail:

  FAIL TRANSLUCENT_SELECT_BECOMES_OPAQUE popup has expected background color (no top coat) - Got "rgb(245, 245, 247)", expected "rgb(255, 255, 255)"
Stack trace:
chrome://mochikit/content/browser-test.js:test_is:1485
chrome://mochitests/content/browser/browser/base/content/test/forms/browser_selectpopup_colors.js:testSelectColors:439
  FAIL TRANSLUCENT_SELECT_APPLIES_ON_BASE_COLOR popup has expected background color (no top coat) - Got "rgb(245, 105, 107)", expected "rgb(255, 115, 115)"
Stack trace:
chrome://mochikit/content/browser-test.js:test_is:1485
chrome://mochitests/content/browser/browser/base/content/test/forms/browser_selectpopup_colors.js:testSelectColors:439

Would need to check automation as well since the test is skipped. Other than that it's just a UX decission.

Comment 80

[support]

quick testresult:

   Working style attributes:  color, background, font-*

Not working style attributes: line-height, border, padding ... and i can't blame the engine for it as it's in a select box context ;)

Other attributes have not been checked and do not make any sense in the context anyway.

Conclusion: rationally working as expected. I upload a blurred image ( content needs to be private, but will do )

Comment 81

[support]

Attachment: really long select box with different styles on eachoption tag + base css class

Comment 82

[Emilio Cobos Álvarez (:emilio)]

Yeah, supported properties are in https://searchfox.org/mozilla-central/rev/b4150d1c6fae0c51c522df2d2c939cf5ad331d4c/toolkit/actors/SelectChild.jsm#29-44

Comment 83

[support]

except for "direction", which hasn't been tested, the above test works. "text-shadows" works, but i have my doubts abouts it's usefullness :)