userContent.css changes to <select> background colour on Firefox 73 take effect only if the <select> is a child of a <div>
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: ssb22, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0
Steps to reproduce:
In my ~/.mozilla/firefox/*.default/chrome/userContent.css I am trying to achieve a "dark" mode (for medical reasons), so I put:
select { background: black }
(among other things of course, but the above item is sufficient to reproduce the bug). Then I visit a test HTML file with:
<html><body>
<select><option>1</option><option>2</option></select>
</body></html>
Actual results:
The background of the "select" element remains white. If the text colour is also set to white, then it is unreadable (white on white).
Notes:
-
This bug seems to be related only to
userContent.cssi.e. I cannot reproduce it by including the same CSS in the page "normally"; -
The problem goes away if I put a
<div>around the<select>, i.e.:<html><body>
<div><select><option>1</option><option>2</option></select></div>
</body></html>
but only if the <select> is directly inside a <div> (not if we have <select> within <form> within <div>, or <select> within <td> within <tr> within <table> within <div>, etc);
- Firefox 69 similarly used to force a white background on
<select>but it could be worked around by havinguserContent.cssset-moz-appearancetonone, but this workaround is no longer possible in Firefox 73.
Expected results:
The background of the "select" element should have been changed by userContent.css.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
That dependency on the <div> or such is very very odd.
Would be interesting to know what regressed this. Thanks for filing!
|
|
||
Comment 2•5 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
20200217142647
(In reply to Silas S. Brown from comment #0)
having
userContent.cssset-moz-appearancetonone, but this workaround is no longer possible in Firefox 73.
Works for me.
- The problem goes away if I put a
<div>around the<select>
Doesn't work for me. No effect without -moz-appearance: none
(among other things of course
I suggest testing in a brand new profile. Don't forget to enter about:config into the address bar, set toolkit.legacyUserProfileCustomizations.stylesheets to true and restart. If you can still reproduce the problem, it would be very helpful if you could find the exact regression range.
|
Reporter | |
Comment 3•5 years ago
|
||
Thanks. Yes I did clear my userContent.css and add just those two lines before reporting the bug, but I forgot to do the same when I said the -moz-appearance: none workaround no longer works.
It turns out the reason why -moz-appearance: none no longer worked on my system is that Firefox now also obeys -webkit-appearance: listbox (which it previously ignored, and I had that rule so I could use the same CSS in Webkit-based browsers and expected Firefox to ignore the -webkit- rules), and the -moz-appearance: none must now come after the -webkit-appearance: listbox if both are given for the select element (if the webkit rule is the one that is listed later then that takes priority). This is something I can fix in my CSS files.
Additionally, I had a spurious div > * rule elsewhere in my CSS which specified -moz-appearance: none (this was due to a bug in the script I was using to generate the CSS) and I've now confirmed that was the explanation of the "child of <div>" exception. Sorry to miss this before reporting.
|
|
||
Updated•5 years ago
|
Description
•