Unable to style <optgroup> label's background
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
People
(Reporter: silv3rwind, Assigned: emilio)
References
Details
Attachments
(3 files)
Updated•8 years ago
|
Updated•8 years ago
|
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
Comment 3•8 years ago
|
||
Comment 5•7 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 7•6 years ago
|
||
This is the code that handles it: https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/toolkit/modules/SelectParentHelper.jsm#405
Somebody needs to look at why the optgroup background is not getting inserted in the stylesheet or otherwise not honored.
Comment 8•5 years ago
|
||
I have the same problem, tested with FF 77.0.1 in Windows 10. See https://arnowelzel.de/en/tools/spoke-length-calculator.
All optgroup labels are with a light grey background even though they should be white. In "dark mode" the dark background is also ignored. As a workaround I styled the text for optgroup elements with a medium grey (#888) so it stays at least readable in dark mode since other browser.
Comment 9•5 years ago
|
||
(In reply to Arno Welzel from comment #8)
I have the same problem, tested with FF 77.0.1 in Windows 10. See https://arnowelzel.de/en/tools/spoke-length-calculator.
All optgroup labels are with a light grey background even though they should be white. In "dark mode" the dark background is also ignored. As a workaround I styled the text for optgroup elements with a medium grey (#888) so it stays at least readable in dark mode since other browser.
As a workaround I now use a minimal different background-color:
select, option { background-color: #fff; color: #000 }
optgroup { background-color: #fffffe; color: #000 }
Visually you barely see a difference, but at least Firefox will not ignore this background colour.
As a minimal test case to verify this bug and to see the result of the workaround see here:
Assignee | ||
Comment 10•5 years ago
|
||
Ah! interesting, thanks!
So this is this check, which prevents us from adding the relevant CSS rule, and then this rule which prevents us from actually using the background color from the <select>
.
So I think that rule should be removed, ideally, or if it's not possible, then we need to figure out something else.
Assignee | ||
Comment 11•5 years ago
|
||
(That CSS is windows-only, which is why I couldn't reproduce here from Linux)
Comment 12•5 years ago
|
||
Any update for this fix? We also have the issue on ProtonMail v4 in the Advanced search in dark mode. :-\
Comment 13•5 years ago
|
||
As already mentioned: as a workaround you may use slightly different colors, that's what I do at https://arnowelzel.de/en/tools/spoke-length-calculator:
option {
background-color: #ffffff;
}
optgroup {
background-color: #fffffe;
}
Visually there is no noticable difference between the option group header and the options, but it's enough for Firefox to paint the option group headers with the given color.
Assignee | ||
Comment 14•5 years ago
|
||
There's also a suggested fix in comment 10. I guess I can boot on Windows and test my suggested fix, I was on Linux when writing that and it fell off my radar (but it's a relatively easy patch to write hopefully).
Assignee | ||
Comment 15•5 years ago
|
||
Most of the test-cases here work data:text/html,<select style="background: red"><optgroup label="Foo"><option>Bar</option><option>Baz</option></optgroup></select>
is bug 1421373 and is an issue only on windows. Patch incoming.
Assignee | ||
Comment 16•5 years ago
|
||
So that they use the select background color by default. The code in
SelectParent expects this when figuring out whether to set background colors
too. This matches other browsers and MacOS, see:
data:text/html,<select style="background: red"><optgroup label="foo"><option>Bar</option><option>Baz</option></optgroup></select>
Updated•5 years ago
|
Comment 17•5 years ago
|
||
![]() |
||
Comment 18•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Comment 20•5 years ago
|
||
I have reproduced this issue using Firefox 57.0a1 (2017.08.25) on macOS 10.15.
I can confirm this issue is fixed, I verified using Firefox 84.0b4, on macOS 10.15, Windows 8.1 x64 and Ubuntu 18.04 x64.
Description
•