Closed Bug 1343570 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

54 Branch
Unspecified
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox54 + fixed
firefox55 --- verified

People

(Reporter: totallymike, Assigned: jaws)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

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.
Attached image screenshot.png
WFM with FF54 on Win 7.
Component: Untriaged → Layout: Form Controls
OS: Unspecified → Mac OS X
Product: Firefox → Core
I can confirm that it works on Windows 10 as well.  Thanks for giving this a test!
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)
You're correct. Disabling electrolysis yields correct behavior.
It's weird because bug 910022 should have been fixed this issue.

Jared, is it a known issue (dupe)?
Blocks: e10s-select
Flags: needinfo?(jaws)
Summary: Option elements shouldn't inherit color attribute from parent select without also inheriting background-color? → [e10s] <option> elements don't inherit background-color attribute from parent <select> on Mac OS X
mconley, I thought bug 1336301 would have fixed this. Did we miss setting -moz-appearance: none?
Flags: needinfo?(jaws) → needinfo?(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?
Flags: needinfo?(mconley) → needinfo?(jaws)
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
Flags: needinfo?(jaws)
Flags: needinfo?(jaws)
Attachment #8843015 - Flags: review?(mconley)
[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.
Assignee: nobody → jaws
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(jaws)
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
Attachment #8843015 - Flags: review?(mconley) → review+
Pushed by jwein@mozilla.com:
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 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
Attachment #8843015 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/45afe80ae477
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Today's nightly shows the fix. Nicely done!
Attached image Corrected behavior
(In reply to Michael Westbom from comment #17)
> Today's nightly shows the fix. Nicely done!

Thanks!
Status: RESOLVED → VERIFIED
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+.
Attachment #8843015 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.