910022 - [e10s] Properly style <option> elements in the parent process UI (support color and background on select options)

Status: RESOLVED FIXED

Description

[:Felipe Gomes (needinfo me!)]

In bug 897060 we implemented support for displaying the dropdowns from <select> widgets in the parent, by opening a menupopup filled with menuitems equivalent to the content from the <option> <optgroup> children elements from the <select> widget.

However, the rendering is not equivalent because the CSS styles that affect the rendering of these elements are not passed to the parent.

Not every CSS property is supported in them, but several are, such as: color, background-color, margins, paddings, font, font-size, font-weight, text-decoration, etc. (p.s. I don't know where to find the exhaustive list)

There are some non-straightforward issues to solve, such as:
 - :hover style
 - figure out if we want native menupopup look, or native dropdown look
 - if we want native menu look, we need to take care of the default styles which are different between <option> and <menuitem>
 - big messages through the message manager are not cheap, so it's probably not good to send all computed styles for every item and every supported CSS property

Comment 1

[:Felipe Gomes (needinfo me!)]

This bug also blocks bug 910022 for reasons explained in bug 910022 comment 0 part (3)

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Webkit/Blink support minimal styling of the options --- text color/background color of each option and the background of the dropdown, and that's about it. And note that when we display the currently selected item in the <select> element itself, that uses none of the option's styles. So I don't think we need to do much here; I'd be fine to limit to what Webkit/Blink support.

I didn't test whether they support :hover or other psuedostyles on <option>s.

I think taking this opportunity to go for a clean break and use native dropdowns (or native look-and-feel with a XUL-based implementation) might be a good idea.

Comment 8

[Bartosz Piec]

Could you please rethink not fixing this bug before releasing e10s? It will break many sites and I don't believe that any web developer is aware of this…

Comment 10

[Boris Zbarsky [:bz] (no decent commit message means r-)]

Note that there are other rendering problems this causes because the XUL styling doesn't match the expected styling even in the absence of website styles.  See bug 1208297.

Comment 11

[Victor Grousset[:tuxayo]]

Can someone confirm that bug 1196892 is indeed a duplicate of this one?
And if yes, explain why. To remove all doubts due to misunderstanding.

Comment 14

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Jim: I think we need to get more info on this bug, for example what the engineering effort would be to mimic blink/webkit's level of support as roc mentions:

(In reply to Robert O'Callahan (:roc) (Exited; email my personal email if necessary) from comment #2)
> Webkit/Blink support minimal styling of the options --- text
> color/background color of each option and the background of the dropdown,
> and that's about it. And note that when we display the currently selected
> item in the <select> element itself, that uses none of the option's styles.
> So I don't think we need to do much here; I'd be fine to limit to what
> Webkit/Blink support.
> 
> I didn't test whether they support :hover or other psuedostyles on <option>s.
> 
> I think taking this opportunity to go for a clean break and use native
> dropdowns (or native look-and-feel with a XUL-based implementation) might be
> a good idea.

Comment 15

[Jim Mathies [:jimm]]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #14)
> Jim: I think we need to get more info on this bug, for example what the
> engineering effort would be to mimic blink/webkit's level of support as roc
> mentions:
> 
> (In reply to Robert O'Callahan (:roc) (Exited; email my personal email if
> necessary) from comment #2)
> > Webkit/Blink support minimal styling of the options --- text
> > color/background color of each option and the background of the dropdown,
> > and that's about it. And note that when we display the currently selected
> > item in the <select> element itself, that uses none of the option's styles.
> > So I don't think we need to do much here; I'd be fine to limit to what
> > Webkit/Blink support.
> > 
> > I didn't test whether they support :hover or other psuedostyles on <option>s.
> > 
> > I think taking this opportunity to go for a clean break and use native
> > dropdowns (or native look-and-feel with a XUL-based implementation) might be
> > a good idea.

Personally I like the follow up idea roc has where he suggests we make a clean break and not support custom styling at all. If we add partial support we risk looking broken thanks to partial styling.

As far as level of effort goes, getting the background color and a font size over is probably pretty easy, getting that set on the new dropdown dealing with layout and alignment issues *might* take some tweaking once QA and users get a hold of this.

Also, If we do block on this I think we probably won't be able to uplift very far. I'd like to suggest making this +/P1 and kick off a discussion with web compat people and fx front end on what we want to support here first.

Comment 16

[Jim Mathies [:jimm]]

gwright, have you ever looked into shipping basic style info over for this? Wondering what the level of effort might be.

Comment 17

[George Wright (:gw280) (needinfo me!)]

We already send down some basic style info such as style.display. I think we opted not to support styling for the most part in e10s selects, especially as Chrome/Safari don't support it.

What info would we want to ship in a "basic style info" payload?

Comment 18

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Jim Mathies [:jimm] from comment #15)
...
> Also, If we do block on this I think we probably won't be able to uplift
> very far. I'd like to suggest making this +/P1 and kick off a discussion
> with web compat people and fx front end on what we want to support here
> first.

Seems reasonable.

Comment 20

[Julian Descottes [:jdescottes][:julian]]

If we don't support styling for selects, shouldn't we do it for both e10s and non-e10s selects? And/or document it somewhere?
Not sure what is the best place to document this kind of things? Maybe a note on MDN (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option)?

A user was confused by this change (https://bugzilla.mozilla.org/show_bug.cgi?id=1291306#c6) and I spent quite some time understanding why this was only working on FF48 for me, not finding any documentation about a change on <option> styling. And e10s is not the first thing you think about when investigating a styling issue.

Jeff: what do you think about this?

Comment 21

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Julian Descottes [:jdescottes] from comment #20)
> If we don't support styling for selects, shouldn't we do it for both e10s
> and non-e10s selects? And/or document it somewhere?
> Not sure what is the best place to document this kind of things? Maybe a
> note on MDN
> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option)?
> 
> A user was confused by this change
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1291306#c6) and I spent quite
> some time understanding why this was only working on FF48 for me, not
> finding any documentation about a change on <option> styling. And e10s is
> not the first thing you think about when investigating a styling issue.
> 
> Jeff: what do you think about this?

I'm not working directly on e10s currently and am not up to speed on what has been done with this issue. I assume that since this bug is still open nothing has been done yet, which is in line with the priority we assigned to it eg it did not block shipping e10s.

Jim: do you have an update on where we are with this?

Comment 22

[Jim Mathies [:jimm]]

documentation would be good. Layout will have to prioritize this work, the e10s team isn't going to work on it.

Comment 23

[Jet Villegas (:jet)]

If I read this bug correctly, there are two possible directions to a fix:
1. Match WebKit/Blink control styling behavior
   If we do this, we should spec it and enable the limited set of style options.
2. Render native or native-looking controls
   If we do this I think we should use real native controls. The maintenance burden of fake native controls seems too high.

In either case, I agree that it should be identical for e10s or non-e10s. 

mconley: what does Platform UX think?

Comment 24

[Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos]

(In reply to Jet Villegas (:jet) from comment #23)
> mconley: what does Platform UX think?

To be clear, I'm Platform UI - not UX. So my perspective is not coming from a design sense, but an engineering sense.

Above all, I think what we need to do here is be consistent. Right now, we have two completely different implementations for <select> dropdown - one for e10s, and one for non-e10s. We should try to combine these so that we only have a single codepath to worry about.

I'm in the camp that native look, feel and function is a great starting point for these controls, but if there are ways that we can improve upon them, we should consider it.

Perhaps not coincidentally, I'll be working with :jaws from the Firefox org and some MSU students to do the following in the Fall:

1) Combine the e10s and non-e10s <select> dropdown logic
2) Restyle the select dropdowns to adhere to this spec: https://bugzilla.mozilla.org/show_bug.cgi?id=1091592
3) Investigate and implement improvements to the dropdown, including (but not limited to) search capability for very long lists (see the spec at https://bug1091592.bmoattachments.org/attachment.cgi?id=8776005 for details).

With regards to styles coming up from content, WebKit parity (text colour and background colour) makes sense, so long as we're consistent.

Comment 25

[George Wright (:gw280) (needinfo me!)]

I think it's worth noting that Chrome isn't consistent between platforms. If I remember correctly, Chrome on OS X doesn't support styling at all (or a very limited amount) in select dropdowns, whereas on Windows it supports more.

Comment 28

[Mark Foley]

I'm not sure of the nuts-and-bolts of this issue as discussed, but I can report that our office had no problem with this up through version 48.0.2. When 2 of the workstations got updated to 49.0, the text in the <option> tags shrunk to some unknown (12pt?) font size. Nothing I've tried will restore it to the same font size as the <select>. Only those users whose workstations (Windows 7, btw) are seeing this problem. Those still on 48.0.2 see the <option> font sizes correctly. Nor was there any such problem since we started using Firefox which was about 4 months ago. My conclusion is that something in the new release of 49.0 broke this.

Comment 29

[radgum]

Easy question: return support for styling selects?

Comment 32

[alex.sudakar]

(In reply to Mark Foley from comment #28)

> I'm not sure of the nuts-and-bolts of this issue as discussed, but I can
> report that our office had no problem with this up through version 48.0.2.
> ...
> My conclusion is that
> something in the new release of 49.0 broke this.

Our experience is exactly the same as Mark's.  We style some <option> elements with various background-color colors (nothing fancier), and this is no longer working for Firefox 49.0.1 on Windows 7.  (Firefox 49.0.1 on XP doesn't have the problem.)

Comment 33

[info]

(In reply to alex.sudakar from comment #32)
> (In reply to Mark Foley from comment #28)
> 
> > I'm not sure of the nuts-and-bolts of this issue as discussed, but I can
> > report that our office had no problem with this up through version 48.0.2.
> > ...
> > My conclusion is that
> > something in the new release of 49.0 broke this.
> 
> Our experience is exactly the same as Mark's.  We style some <option>
> elements with various background-color colors (nothing fancier), and this is
> no longer working for Firefox 49.0.1 on Windows 7.  (Firefox 49.0.1 on XP
> doesn't have the problem.)

Our experience is the same, we use styled options with different background colors.
But after some more testing I noticed Firefox isn't the only one, Chrome on Mac will also not show any styling. And if you have mobile users it getting worse.
Styling selects cross browser is really a nightmare:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Advanced_styling_for_HTML_forms#Dealing_with_the_select_nightmare

If you need styled options, you're best chance is to use a jQuery plugin (something like https://select2.github.io/), to replace the select.
This is currently the only way to get the same results cross-browser.

Comment 34

[Robert Kaiser]

(In reply to info from comment #33)
> Styling selects cross browser is really a nightmare:

Styling HTML "form elements" of most kinds is a nightmare, and IMHO one of the big remaining pieces why HTML is still not a good UI language (and XUL still trumps it). I'd really wish TPTB in WHATWG/W3C would get that fixed by standards and implementations.

Comment 35

[RadarNyan]

Well I always thought styling <select> element would work since I've seen a lot sites do that, guess that's just because I'm on Windows all the time. So I did some Internet search and found this:

http://archivist.incutio.com/viewlist/css-discuss/39858
>The select element is part of the operating system, not the browser chrome.

IMHO, if that stands true, shouldn't Firefox just follow what the Browser comes with the OS does? Like Google Chrome: styles it on Windows (like IE), doesn't style it on OS X (like Safari)

Comment 39

[Zéfling]

Created attachment 8799058 [details]
Firefox_39_Option.png

Why only  color and background ? I use also the border like separators.

For me, it is incomprehensible that we can not put HTML in <option> tags. Why ? It is more easier to rebuild a <select> with non-from elements.

Comment 45

[jkirk_14]

Disappointing to see styling in select dropdowns no longer supported.  In some instances, it's quite impactful.

Comment 47

[guerin45]

Please remove also the ugly blue background-color appearing on mouse over disabled items.


Don't know if it is always possible, but if you could also support the ::before and ::after pseudo-elements, It will be useful to show icon on option.

This is the CSS style I use until now:
option.icon-sysUser::before {
    background-color: #CFC;
}
.icon-sysUser::before {
    background-position: -126px -378px;
}
option.icon::before {
    margin: 1px 3px 1px 0;
    background-image: url(/images/sprite.png);
    width: 18px;
    height: 18px;
    content: "";
    display: inline-block;
    vertical-align: middle;
    margin-right: 4px;
}

Comment 48

[Jared Beach]

Created attachment 8818718 [details]
Bug 910022 - Allow styling of <option> elements color & background color on windows

Allows styling of color/background color for options in select dropdowns. Bug still exists with this patch where the selected item of non-styled dropdowns retains the "custombgcolor" attribute.

Review commit: https://reviewboard.mozilla.org/r/98670/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/98670/

Comment 49

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to guerin45 from comment #47)
> Please remove also the ugly blue background-color appearing on mouse over
> disabled items.

This is already removed in Nightly. I can't reproduce this issue with the following web page:
data:text/html,<select><option disabled>test<option>test2<option>test3
 
> Don't know if it is always possible, but if you could also support the
> ::before and ::after pseudo-elements, It will be useful to show icon on
> option.

This isn't possible now and we don't have any plans to support it.

Comment 50

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8818718 [details]
Bug 910022 - Allow styling of <option> elements color & background color on windows

https://reviewboard.mozilla.org/r/98670/#review100232

I have updated beachjar's patch to work on top of the patch that I am implementing in bug 1323618. Once bug 1323618 lands then we can push forward on this one.

Comment 53

[colinrice07]

Here is a test case of the issues I am having http://jsfiddle.net/ovz4n1h8/

Comment 54

[Vasilis Lourdas]

I've just upgraded to 51, but up to 50.1.0 e10s was disabled because of a couple of addons I use. Because this bug is very annoying for me (it's a major UI annoyance for the end users if you style options in select lists that are semantically different from one another), is there a way to disabled e10s in this new version? When will there be a fix for it?

Comment 55

[Jared Wein [:jaws] (please needinfo? me)]

Created attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

Portions of the patch were written by Jared Beach ([e-mail])

Review commit: https://reviewboard.mozilla.org/r/107588/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/107588/

Comment 56

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/107588/diff/1-2/

Comment 58

[Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos]

Comment on attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

https://reviewboard.mozilla.org/r/107588/#review109388

Tested this on OS X (after I applied my fix - see below). Thanks!

::: browser/base/content/test/general/browser_selectpopup.js:742
(Diff revision 2)
>    yield BrowserTestUtils.removeTab(tab);
>  });
>  
> +add_task(function* test_colors_applied_to_popup() {
> +  function inverseRGBString(rgbString) {
> +    let [, r, g, b] = rgbString.match(/^rgb\((\d+),\s*(\d+),\s*(\d+)\)$/);

Nit: I'm not the hugest fan of the `[, x, y, z]` pattern for dropping the first element. Not going to block on this, but I'd honestly prefer the more explicit:

`let [unused, r, g, b] = ...`

Feel free to drop though.

::: browser/base/content/test/general/browser_selectpopup.js:746
(Diff revision 2)
> +  function inverseRGBString(rgbString) {
> +    let [, r, g, b] = rgbString.match(/^rgb\((\d+),\s*(\d+),\s*(\d+)\)$/);
> +    return `rgb(${255 - r}, ${255 - g}, ${255 - b})`;
> +  }
> +
> +  const pageUrl = "data:text/html," + escape(PAGECONTENT_COLORS);

Can you avoid the escape by doing:

```
const pageUrl = `data:text/html,${PAGECONTENT_COLORS}`;
```

?

Also, should this be PAGE_URL?

::: browser/base/content/test/general/browser_selectpopup.js:765
(Diff revision 2)
> +    // We need to use Canvas here to get the actual pixel color
> +    // because the computedStyle will only tell us the 'color' or
> +    // 'backgroundColor' of the element, but not what the displayed
> +    // color is due to composition of various CSS rules such as
> +    // 'filter' which is applied when elements have custom background
> +    // or foreground elements.
> +    let canvas = document.createElementNS("http://www.w3.org/1999/xhtml", "canvas");
> +    canvas = document.documentElement.appendChild(canvas);
> +    let rect = child.getBoundingClientRect();
> +    canvas.setAttribute("width", rect.width);
> +    canvas.setAttribute("height", rect.height);
> +    canvas.mozOpaque = true;
> +
> +    let ctx = canvas.getContext("2d");
> +    ctx.drawWindow(window, rect.x + rect.left, rect.y + rect.top, rect.width, rect.height, "#000", ctx.DRAWWINDOW_USE_WIDGET_LAYERS);
> +    let frame = ctx.getImageData(0, 0, rect.width, rect.height);
> +
> +    let pixels = frame.data.length / 4;
> +    // Assume the inverse backgroundColor is the color of the first pixel.
> +    let [inverseBgR, inverseBgG, inverseBgB] = frame.data;
> +    let inverseBackgroundColor = `rgb(${inverseBgR}, ${inverseBgG}, ${inverseBgB})`;
> +    // Use the next different pixel color as the foreground color, assuming
> +    // no anti-aliasing.
> +    let inverseColor = inverseBackgroundColor;
> +    for (let i = 0; i < pixels; i++) {
> +      if (frame.data[i * 4 + 0] == 246) { alert("got toolbar color"); };
> +      if (inverseBgR != frame.data[i * 4 + 0] &&
> +          inverseBgG != frame.data[i * 4 + 1] &&
> +          inverseBgB != frame.data[i * 4 + 2]) {
> +        inverseColor = `rgb(${frame.data[i * 4 + 0]}, ${frame.data[i * 4 + 1]}, ${frame.data[i * 4 + 2]})`;
> +      }
> +    }

I feel like this is the sort of thing that makes for a good helper function, but it's not a strong feeling.

::: browser/base/content/test/general/browser_selectpopup.js:790
(Diff revision 2)
> +    let inverseBackgroundColor = `rgb(${inverseBgR}, ${inverseBgG}, ${inverseBgB})`;
> +    // Use the next different pixel color as the foreground color, assuming
> +    // no anti-aliasing.
> +    let inverseColor = inverseBackgroundColor;
> +    for (let i = 0; i < pixels; i++) {
> +      if (frame.data[i * 4 + 0] == 246) { alert("got toolbar color"); };

Leftover debugging?

::: toolkit/modules/SelectContentHelper.jsm:228
(Diff revision 2)
>                                : child.text;
>        if (textContent == null) {
>          textContent = "";
>        }
>  
> +      DOMUtils.addPseudoClassLock(child, ":checked", false);

Mind adding a comment here about how we're locking off the :checked pseudoclass so that we can get the true styles of the `selected` item?

::: toolkit/themes/osx/global/menu.css:138
(Diff revision 2)
>  menuitem[_moz-menuactive="true"] {
>    color: -moz-mac-menutextselect;
>    background-color: Highlight;
>  }
>  
> +menuitem[_moz-menuactive="true"][customoptionstyling="true"] {

At least for OS X, I think you're going to need to add this:

```css
menuitem[customoptionstyling="true"] {
  -moz-appearance: none;
  padding-top: 0px;
  padding-bottom: 0px;
}
```

The padding is optional, but it gets rid of space above the top element and below the bottom element which might clash with the background colours. If we don't care about that, you can get rid of that change. But the -moz-appearance is definitely necessary in order to be able to set the background colours.

Comment 59

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

https://reviewboard.mozilla.org/r/107588/#review109388

> Nit: I'm not the hugest fan of the `[, x, y, z]` pattern for dropping the first element. Not going to block on this, but I'd honestly prefer the more explicit:
> 
> `let [unused, r, g, b] = ...`
> 
> Feel free to drop though.

Adding in 'unused' causes an eslint error for 'no-unused-vars'. We can add 'unused' to the list of ignored variable names for the rule in /toolkit/.eslintrc.js, but I didn't want to do that in this patch.

> Can you avoid the escape by doing:
> 
> ```
> const pageUrl = `data:text/html,${PAGECONTENT_COLORS}`;
> ```
> 
> ?
> 
> Also, should this be PAGE_URL?

pageUrl and escape are used heavily within this test file. I didn't want to break with that. We can file a follow-up to clean up this test though, it would be a nice good-first-bug.

Comment 60

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8830923 [details]
Bug 910022 - Allow websites to provide custom background colors and foreground colors for <select> popups.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/107588/diff/2-3/

Comment 61

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/74d0d2f2b19c
Allow websites to provide custom background colors and foreground colors for <select> popups. r=mconley

Comment 62

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/74d0d2f2b19c

Comment 65

[Astley Chen [:astley] (UTC+8)]

Per regression bug 1315401, do we consider to uplift to Firefox 52/53 ?

Comment 66

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Astley Chen [:astley] (UTC+8) from comment #65)
> Per regression bug 1315401, do we consider to uplift to Firefox 52/53 ?

We're still dealing with fallout from this patch, with one fix just landed in bug 1335483 and another one up for review in bug 1336125. After those two patches have landed and stabilized we can uplift assuming no other bugs have been reported.

Comment 67

[Jared Wein [:jaws] (please needinfo? me)]

[Tracking Requested - why for this release]: noticeable regression for form controls that will increase as adoption of e10s increases. see comment 66 for notes about two regressions that will need to be uplifted along with this bug.

Comment 68

[Lee McFarland]

Might the resolution of this issue have caused the problem reported by bug 1336301?  
In that case, items in a drop-down are only visible when the mouse cursor is on them,
all other possibilities being invisible.

Comment 69

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Lee McFarland from comment #68)
> Might the resolution of this issue have caused the problem reported by bug
> 1336301?  
> In that case, items in a drop-down are only visible when the mouse cursor is
> on them,
> all other possibilities being invisible.

Yes, the changes here caused that bug. Thank you for your report, I've confirmed that it isn't fixed by the other follow-up patches.

Comment 71

[Liz Henry (:lizzard) (needinfo? me)]

Tracking since this sounds like an annoying regression in form controls.

Comment 75

[Julien Cristau [:jcristau]]

If this needs to be fixed in 52, it has to be really soon now, we're building the last beta before RC today.  Or should this be deferred to 53?

Comment 76

[Jared Wein [:jaws] (please needinfo? me)]

We now have a kill-switch (via the dom.forms.select.customstyling pref) so we could uplift it to 52 and then if an issue arises we could disable the feature by setting the pref to false for all users.

If this patch were to be uplifted, we would need to uplift this along with all of the follow-up patches to fix related regressions, which are numerous.

Uplifting to 52 would limit fix the regression for users who got on e10s earlier, and prevent it from being seen for users who still haven't been migrated to e10s. However, we would have to be monitoring feedback about broken forms and be willing to ship out a hotfix that disables the pref if necessary.

Considering all of the above, I would prefer to uplift to 53 and track there.

Comment 77

[Julien Cristau [:jcristau]]

wontfix for 52 per comment 76 and irc discussion between jaws and mconley.

Comment 78

[Liz Henry (:lizzard) (needinfo? me)]

jaws, are you still intending to uplift all of this to 53?

Comment 79

[Liz Henry (:lizzard) (needinfo? me)]

Oops, just wontfixed entirely the wrong bug.

Comment 80

[Jared Wein [:jaws] (please needinfo? me)]

I thought we were going to be OK to uplift to 53 but I just saw bug 1346440 get reported over the weekend so I think we should hold off. I do have a patch on that bug which fixes the issue though.

Comment 81

[Liz Henry (:lizzard) (needinfo? me)]

Marking fix-optional to get this off my triage list. We can still consider uplift for this and the patch in bug 1346440, just nominate it for beta if you think it is worth the risk. The next beta build will be for beta 7 on Monday.

Comment 82

[Julien Cristau [:jcristau]]

wontfix for 53 based on https://bugzilla.mozilla.org/show_bug.cgi?id=1346440#c17

Comment 83

[684sigma]

Hello.
It was said in this bug that Firefox will support support color and background on select options, but it's still unknown to what extent it will. In non-e10s just everything works. I haven't found anything like "the new spec" in this bug, so I tried some possible cases of styling and filed these bugs to get complete answer from developers.
There're 3 cases how color and background of an option can change: by pseudoclasses, CSS transitions and JS. Unfortunately I had to file pseudoclasses separately. I still think that "the new spec" should exist in some form, if e10s isn't going to support all the cases.

Comment 84

[Eric Shepherd [:sheppy]]

Updated:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option
https://developer.mozilla.org/en-US/Firefox/Releases/54

Comment 85

[b.bellec]

Will this be fixed on ESR 52 ?

Comment 86

[Jared Wein [:jaws] (please needinfo? me)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Fixes a regression that got introduced with e10s, developers will again be able to style select popups (background and foreground colors)
[Affects Firefox for Android]: no
[Suggested wording]: <select> menus can have custom background and foreground colors
[Links (documentation, blog post, etc)]: n/a

Comment 87

[Dão Gottwald [::dao]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #86)
> Release Note Request (optional, but appreciated)
> [Why is this notable]: Fixes a regression that got introduced with e10s,
> developers will again be able to style select popups (background and
> foreground colors)
> [Affects Firefox for Android]: no
> [Suggested wording]: <select> menus can have custom background and
> foreground colors
> [Links (documentation, blog post, etc)]: n/a

Note that this feature is currently still disabled on Linux bug 1338283, so we can't really advertise it as broadly.

Comment 88

[Dão Gottwald [::dao]]

(In reply to Dão Gottwald [::dao] from comment #87)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #86)
> > Release Note Request (optional, but appreciated)
> > [Why is this notable]: Fixes a regression that got introduced with e10s,
> > developers will again be able to style select popups (background and
> > foreground colors)
> > [Affects Firefox for Android]: no
> > [Suggested wording]: <select> menus can have custom background and
> > foreground colors
> > [Links (documentation, blog post, etc)]: n/a
> 
> Note that this feature is currently still disabled on Linux bug 1338283, so
> we can't really advertise it as broadly.

I meant "... due to bug 1338283", and I suppose this should be noted here too:

(In reply to Eric Shepherd [:sheppy] from comment #84)
> Updated:
> 
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option
> https://developer.mozilla.org/en-US/Firefox/Releases/54

Comment 89

[Mark Foley]

Perhaps this should be a different issues, but my post #28 is was about specifying attributes for <select> ... <option> tags. My problem is that the <option> entries appear to be in some much reduced font from what was sepcified for the <select> style. Despite the security and privacy superiority of Firefox this is driving my users crazy and making them want to go back to IE -- they can't "see" privacy! As I mentioned in comment #28, this started happening in 48.0.2. I am current on 53.0.3 (Windows) and the issue still exists. Here is an example: http://www.novatec-inc.com/pub/select.jpg. If the <select> font size is bigger, the difference is even more dramatic. I think the option tags should default to inheriting the attributes of the parent select tag.

Comment 90

[Chris Mills (Mozilla, MDN editor) [:cmills]]

(In reply to Dão Gottwald [::dao] from comment #88)
> (In reply to Dão Gottwald [::dao] from comment #87)
> > (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #86)
> > > Release Note Request (optional, but appreciated)
> > > [Why is this notable]: Fixes a regression that got introduced with e10s,
> > > developers will again be able to style select popups (background and
> > > foreground colors)
> > > [Affects Firefox for Android]: no
> > > [Suggested wording]: <select> menus can have custom background and
> > > foreground colors
> > > [Links (documentation, blog post, etc)]: n/a
> > 
> > Note that this feature is currently still disabled on Linux bug 1338283, so
> > we can't really advertise it as broadly.
> 
> I meant "... due to bug 1338283", and I suppose this should be noted here
> too:
> 
> (In reply to Eric Shepherd [:sheppy] from comment #84)
> > Updated:
> > 
> > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option
> > https://developer.mozilla.org/en-US/Firefox/Releases/54

I've added a note in about the Linux contrast issue.

Comment 91

[msuboh]

The Bug Still Exists
Enable the Multi-Process on FireFox 54 64Bit
and Test SNIPPET on This Page: 
https://stackoverflow.com/questions/41244238/firefox-dropdown-option-font-size-not-being-rendered

Application Basics
------------------

Name: Firefox
Version: 54.0
Build ID: 20170608105825
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
OS: Windows_NT 10.0
Multiprocess Windows: 0/1 (Disabled by add-ons)
Google Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports

Extensions
----------

Name: Application Update Service Helper
Version: 2.0
Enabled: true
ID: [e-mail]

Name: Awesome Screenshot - Capture, Annotate & More
Version: 3.0.18
Enabled: true
ID: jid0-GXjLLfbCoAx0LcltEdFrEkQdQPI@jetpack

Name: ColorZilla
Version: 3.3
Enabled: true
ID: {6AC85730-7D0F-4de0-B3FA-21142DD85326}

Name: Copy Plain Text 2
Version: 1.6
Enabled: true
ID: [e-mail]

Name: EverSync - Sync bookmarks, backup your favorites.
Version: 13.1.1
Enabled: true
ID: [e-mail]

Name: Firefox Screenshots
Version: 6.6.0
Enabled: true
ID: [e-mail]

Name: Integrated Authentication for Firefox
Version: 3.0.1.1-signed.1-signed
Enabled: true
ID: [e-mail]

Name: Multi-process staged rollout
Version: 1.50
Enabled: true
ID: [e-mail]

Name: Pocket
Version: 1.0.5
Enabled: true
ID: [e-mail]

Name: Private Tab
Version: 0.2.2
Enabled: true
ID: privateTab@infocatcher

Name: Rainbow
Version: 1.6.1-signed.1-signed
Enabled: true
ID: [e-mail]

Name: Reload Plus
Version: 5.2.1
Enabled: true
ID: reloadplus@blackwind

Name: Restart
Version: 3.0.2
Enabled: true
ID: [e-mail]

Name: Speed Dial [FVD] - New Tab Page, Sync...
Version: 23.0.1
Enabled: true
ID: [e-mail]

Name: Tab Memory Usage
Version: 0.2.7
Enabled: true
ID: jid1-fRvgLzKONCsPew@jetpack

Name: Web Compat
Version: 1.1
Enabled: true
ID: [e-mail]

Name: Web Developer
Version: 1.2.13
Enabled: true
ID: {c45c406e-ab73-11d8-be73-000a95be3b12}

Name: Adblock Plus
Version: 2.9.1
Enabled: false
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

Graphics
--------

Features
Compositing: Direct3D 11
Asynchronous Pan/Zoom: none
WebGL 1 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000006f80) EGL_VERSION: 1.4 (ANGLE 2.1.0.2a250c8a0e15) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses
WebGL 1 Driver Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)
WebGL 1 Driver Version: OpenGL ES 2.0 (ANGLE 2.1.0.2a250c8a0e15)
WebGL 1 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object
WebGL 1 Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug_get OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture
WebGL 2 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000006f80) EGL_VERSION: 1.4 (ANGLE 2.1.0.2a250c8a0e15) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses
WebGL 2 Driver Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)
WebGL 2 Driver Version: OpenGL ES 3.0 (ANGLE 2.1.0.2a250c8a0e15)
WebGL 2 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object
WebGL 2 Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug_get OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc
Audio Backend: unknown
Direct2D: true
DirectWrite: true (10.0.15063.413)
GPU #1
Active: Yes
Description: Intel(R) HD Graphics 4600
Vendor ID: 0x8086
Device ID: 0x0412
Driver Version: 20.19.15.4326
Driver Date: 11-16-2015
Drivers: igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
Subsys ID: 367d17aa
RAM: Unknown

Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: skia
Decision Log
D3D9_COMPOSITING:
disabled by default: Disabled by default
GPU_PROCESS:
unavailable by default: Multi-process mode is not enabled
WEBRENDER:
unavailable by runtime: Build doesn't include WebRender




Important Modified Preferences
------------------------------

accessibility.typeaheadfind: true
accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 1048576
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.hashstats_reported: 1
browser.cache.disk.smart_size.enabled: false
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 2
browser.cache.memory.capacity: 81920
browser.cache.memory.max_entry_size: 81920
browser.download.importedFromSqlite: true
browser.download.useDownloadDir: false
browser.places.smartBookmarksVersion: 8
browser.search.useDBForOrder: true
browser.sessionstore.upgradeBackup.latestBuildID: 20170608105825
browser.startup.homepage: chrome://fvd.speeddial/content/fvd_about_blank.html
browser.startup.homepage_override.buildID: 20170608105825
browser.startup.homepage_override.mstone: 54.0
browser.tabs.closeWindowWithLastTab: false
browser.tabs.remote.autostart.2: true
browser.tabs.remote.force-enable: false
browser.urlbar.autocomplete.enabled: false
browser.urlbar.daysBeforeHidingSuggestionsPrompt: 1
browser.urlbar.lastSuggestionsPromptDate: 20170328
browser.urlbar.maxRichResults: 15
browser.urlbar.suggest.bookmark: false
browser.urlbar.suggest.history: false
browser.urlbar.suggest.openpage: false
dom.ipc.processCount: 10
dom.ipc.processCount.extension: 10
dom.ipc.processCount.webLargeAllocation: 100
extensions.lastAppVersion: 54.0
font.language.group: ar
gfx.crash-guard.d3d11layers.appVersion: 54.0
gfx.crash-guard.d3d11layers.deviceID: 0x0412
gfx.crash-guard.d3d11layers.driverVersion: 20.19.15.4326
gfx.crash-guard.d3d11layers.feature-d2d: true
gfx.crash-guard.d3d11layers.feature-d3d11: true
gfx.crash-guard.status.d3d11layers: 2
gfx.crash-guard.status.d3d11video: 2
gfx.crash-guard.status.d3d9video: 2
media.gmp-eme-adobe.abi: x86_64-msvc-x64
media.gmp-eme-adobe.lastUpdate: 1486714916
media.gmp-eme-adobe.version: 17
media.gmp-gmpopenh264.abi: x86_64-msvc-x64
media.gmp-gmpopenh264.lastUpdate: 1486714916
media.gmp-gmpopenh264.version: 1.6
media.gmp-manager.buildID: 20170608105825
media.gmp-manager.lastCheck: 1497418492
media.gmp-widevinecdm.abi: x86_64-msvc-x64
media.gmp-widevinecdm.lastUpdate: 1486714917
media.gmp-widevinecdm.version: 1.4.8.903
media.gmp.storage.version.observed: 1
media.hardware-video-decoding.failed: false
network.automatic-ntlm-auth.trusted-uris: http://localhost
network.cookie.lifetimePolicy: 2
network.cookie.prefsMigrated: true
network.negotiate-auth.delegation-uris: http://localhost
network.negotiate-auth.trusted-uris: http://localhost
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1497344397
places.history.enabled: false
places.history.expiration.transient_current_max_pages: 122334
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
privacy.donottrackheader.enabled: true
privacy.history.custom: true
privacy.sanitize.sanitizeOnShutdown: true
security.sandbox.content.tempDirSuffix: {f0de8f87-f774-4d20-8f14-3d4bdbf2e9a4}
services.sync.declinedEngines:
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1496644821
ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found.

Important Locked Preferences
----------------------------

Places Database
---------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.14
Version in use: 4.14

NSS
Expected minimum version: 3.30.2
Version in use: 3.30.2

NSSSMIME
Expected minimum version: 3.30.2
Version in use: 3.30.2

NSSSSL
Expected minimum version: 3.30.2
Version in use: 3.30.2

NSSUTIL
Expected minimum version: 3.30.2
Version in use: 3.30.2

Experimental Features
---------------------

Sandbox
-------

Content Process Sandbox Level: 1

Comment 92

[loonar]

Can confirm, OPTION font-size in multiprocess mode in this test snippet (https://stackoverflow.com/questions/41244238/firefox-dropdown-option-font-size-not-being-rendered) is very small. When I disable multiprocess mode, everything is OK. Bug is not fixed.

Name 	Firefox
Version 	54.0
Build ID 	20170608105825
Update History 	
Update Channel 	release
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
OS 	Darwin 16.5.0
Profile Folder 	
Enabled Plugins 	about:plugins
Build Configuration 	about:buildconfig
Memory Use 	about:memory
Performance 	about:performance
Registered Service Workers 	about:serviceworkers
Multiprocess Windows 	1/1 (Enabled by default)
Google Key 	Found
Mozilla Location Service Key 	Found
Safe Mode 	false
Profiles 	about:profiles

Comment 93

[b.bellec]

(In reply to b.bellec from comment #85)
> Will this be fixed on ESR 52 ?

So I have my answer: no, this is not fixed in ESR 52.2.0.
Thanks Mozilla for pushing broken release in ESR channel... Now I have to go on all my users computer to switch off e10s in order to get our internal web app working correctly.

Moreover, this is not completely fixed in Firefox 54. "background-color" style is fixed but not "font-weight" style.

Comment 94

[Mark Foley]

Just downloaded 54.0, Windows 7. Sorry, not fixed. option drop-down list is still in much smaller font than select box.

<select name="thisMbr" onChange="document.findMemberForm.memberId.value=this.options[selectedIndex].value;return document.findMemberForm.submit();">
          <option selected value="">--select Member--</option>
          <option value="073340">-xx-3930  Pxxx, Amy M. (ACT)</option>
          <option value="074680">-xx-2792  Pxxx, Corey W. (ACT)</option>
          <option value="121550">-xx-6463  Pxxx, Harold E. (AGE)</option>
          <option value="021552">-xx-6645  Pxxx, Linda J. (Spouse)</option>
        </select>

Comment 95

[Gerry Chang [:gchang]]

It's already been in MDN. Remove relnote-firefox flag.

Comment 96

[Mark Foley]

(In reply to Gerry Chang [:gchang] from comment #95)
> It's already been in MDN. Remove relnote-firefox flag.

What is "MDN"?

Comment 97

[Loic]

(In reply to Mark Foley from comment #96)
> (In reply to Gerry Chang [:gchang] from comment #95)
> > It's already been in MDN. Remove relnote-firefox flag.
> 
> What is "MDN"?

It's https://developer.mozilla.org/

Comment 98

[hulbert.jason]

- macOS 10.12.5
- FF 54 

Description:
I'm seeing a difference in option style inheritance depending on whether or not a select element is initially focused/opened and when it is opened after already being focused.

Steps:
- Apply a background-color and color to a select element
- Click to focus and expand the select drop

Result:
- Styles ARE NOT inherited by option elements

---

Steps:
- Apply a background-color and color to a select element
- Click to focus and expand the select drop
- Select an option
- Click to focus the expand the select drop again

Results:
- Styles ARE inherited by option elements

---

This issue looks even worse if you apply a transition to the select background-color. Before the transition completes, the option menu appears as browser default. When the transition completes, the option menu abruptly shows inherited background-color and browser defaults appear to be removed to some extent.

Comment 99

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to hulbert.jason from comment #98)
> - macOS 10.12.5
> - FF 54 
> 
> Description:
> I'm seeing a difference in option style inheritance depending on whether or
> not a select element is initially focused/opened and when it is opened after
> already being focused.
> 
> Steps:
> - Apply a background-color and color to a select element
> - Click to focus and expand the select drop
> 
> Result:
> - Styles ARE NOT inherited by option elements
> 
> ---
> 
> Steps:
> - Apply a background-color and color to a select element
> - Click to focus and expand the select drop
> - Select an option
> - Click to focus the expand the select drop again
> 
> Results:
> - Styles ARE inherited by option elements
> 
> ---
> 
> This issue looks even worse if you apply a transition to the select
> background-color. Before the transition completes, the option menu appears
> as browser default. When the transition completes, the option menu abruptly
> shows inherited background-color and browser defaults appear to be removed
> to some extent.

Can you please file a new bug for this? What you are describing should have been fixed by bug 1349701 and bug 1353252.

Comment 100

[hulbert.jason]

Added a new bug here https://bugzilla.mozilla.org/show_bug.cgi?id=1376443