1343570 - [e10s] <option> elements don't inherit background-color attribute from parent <select> on Mac OS X

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Michael Westbom]

Attachment: A minimal document demonstrating the behavior

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170301030202

Steps to reproduce:

Add background-color and color rules to a class associated with a select element. A sufficient example is the following:

select.styled {
  background-color: white;
  color: black;
}


Actual results:

The `color` attribute is inherited by the option elements within the select element, but `background-color` is not. This leads to unreadable option contents.


Expected results:

Either both `background-color` and `color` are inherited, or neither.

Comment 1

[Michael Westbom]

Attachment: A screenshot of the behavior

Comment 2

[Loic]

Attachment: screenshot.png

WFM with FF54 on Win 7.

Comment 3

[Michael Westbom]

I can confirm that it works on Windows 10 as well.  Thanks for giving this a test!

Comment 4

[Loic]

IMHO, it's an issue with e10s on OSX. Could you disable e10s and test again.
https://wiki.mozilla.org/Electrolysis#Nightly.2FAurora (restart Firefox to apply)

Comment 5

[Michael Westbom]

You're correct. Disabling electrolysis yields correct behavior.

Comment 6

[Michael Westbom]

Attachment: Same example case on MacOS with e10s disabled.

Comment 7

[Loic]

It's weird because bug 910022 should have been fixed this issue.

Jared, is it a known issue (dupe)?

Comment 8

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

mconley, I thought bug 1336301 would have fixed this. Did we miss setting -moz-appearance: none?

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Huh. It looks like this rule isn't being applied for the menupopup's:

http://searchfox.org/mozilla-central/rev/31b6089ce26fa76459642765115605d50a6c67b4/toolkit/themes/osx/global/menu.css#138

The menuitem rules apply though. I guess the stylesheet, on OS X, isn't in the right scope to apply to the menupopup?

Any idea where we should put the rule instead?

Comment 10

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

Ah, on Linux we had to put that rule in popup.css,
http://searchfox.org/mozilla-central/source/toolkit/themes/linux/global/popup.css#102-104

Comment 11

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

Attachment: Bug 1343570 - menupopup appearance for customoptionstyling needs to be in popup.css instead of menu.css because menu.css doesn't have access to the parent popup.

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

Comment 12

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

[Tracking Requested - why for this release]: Visible regression related to bug 910022.

Just tested this patch on OSX and confirmed that it fixes the bug.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8843015 [details]
Bug 1343570 - menupopup appearance for customoptionstyling needs to be in popup.css instead of menu.css because menu.css doesn't have access to the parent popup.

https://reviewboard.mozilla.org/r/116754/#review120178

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/45afe80ae477
menupopup appearance for customoptionstyling needs to be in popup.css instead of menu.css because menu.css doesn't have access to the parent popup. r=mconley

Comment 15

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

Comment on attachment 8843015 [details]
Bug 1343570 - menupopup appearance for customoptionstyling needs to be in popup.css instead of menu.css because menu.css doesn't have access to the parent popup.

Approval Request Comment
[Feature/Bug causing the regression]: missed a case as part of bug 910022
[User impact if declined]: <select> menus on some pages may be unreadable
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: just landed on autoland, should be in Nightly within 2 days
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no, simple css fix
[Why is the change risky/not risky?]: see above answer
[String changes made/needed]: none

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/45afe80ae477

Comment 17

[Michael Westbom]

Today's nightly shows the fix. Nicely done!

Comment 18

[Michael Westbom]

Attachment: Corrected behavior

Comment 19

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

(In reply to Michael Westbom from comment #17)
> Today's nightly shows the fix. Nicely done!

Thanks!

Comment 20

[Gerry Chang [:gchang]]

Comment on attachment 8843015 [details]
Bug 1343570 - menupopup appearance for customoptionstyling needs to be in popup.css instead of menu.css because menu.css doesn't have access to the parent popup.

Fix a menupopup appearance issue and was verified. Aurora54+.

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/9df289352cbe