White margin around select dropdowns in the print dialog
Categories
(Toolkit :: Printing, defect, P3)
Tracking
()
People
(Reporter: aminomancer, Unassigned)
Details
Attachments
(1 file)
|
45.27 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
- Have only tested this on Windows 10, FYI. Might be relevant. But I shared this on reddit and it seems to be well-known.
- Enable dark mode (so there's some contrast) e.g. with ui.systemUsesDarkTheme = 1 or by setting the lightweight theme to "Dark"
- Go to any page and hit ctrl+P or file > print.
- Click one of the select elements, like the "Destination" dropdown menu. They all have this problem so it doesn't matter which.
Actual results:
- The <option> elements are apparently drawn on top of a white rectangle that bleeds out from underneath them. Which looks pretty bad, see the attached screenshot.
This doesn't look like a CSS issue, since it's an actual select element with option elements nested inside. There's no container for a border/outline/box-shadow to exist on. And of course there's no trace of that white margin anywhere in the inspector, as far as I can tell.
Other select dropdowns don't have this problem. But I can't remember ever seeing any other select dropdowns in the UI context, so maybe that's the issue. Like, the <option> elements aren't drawn in the contentSelectDropdown, they just show up in the inspector as normal option nodes.
Expected results:
- There shouldn't be a white frame around the option elements, just like there isn't for in-content select => option elements.
| Reporter | ||
Comment 1•5 years ago
|
||
Oh, and for what it's worth, the way the "border" is asymmetric and darker on the bottom and right than on the left and top reminds me of the way input elements appear without additional styling. Although the colors are flipped — normally for a select or input the top and left would be dark and the bottom and right would be light. So this actually looks more like a <button>, where the top and left are light and the bottom and right are dark, in order to look embossed rather than debossed. Maybe that's a hint to the provenance of this little artifact thing? This shows up whether widget.disable-native-theme-for-content is true or false btw.
Comment 2•5 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•4 years ago
|
Description
•