Font is not rendered properly in the dropdown portion of the select tag.
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: rgelbhb, Unassigned)
Details
Attachments
(1 file)
|
36.15 KB,
image/png
|
Details |
2023_02_28_16_57_40_Document_Mozilla_Firefox.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
Steps to reproduce:
If you create a <select> tag and assign it font-family ProximaNova-Regular (one of the Adobe fonts), it renders find in the text portion of the <select>, but not in the dropdown portion. The dropdown portion is rendered using the default Times new roman font.
I provided a sample in https://github.com/rgelb/firefox-font-render-bug repository. It includes sample .html file as well as the font.
I should note that the problem is present with Firefox for Windows. I tested it in Firefox on the Mac and it appeared to render fine. It also renders fine in Chrome and Edge on Windows.
Actual results:
The dropdown portion rendered the font incorrectly.
Expected results:
The dropdown portion rendered the font incorrectly.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
This is because web fonts aren't sent to the parent process, but we need to render the select element there in the parent. In macOS and Linux we (and other browsers) use the system font (so, also not the specified font-face).
You should specify a fallback font anyways (so that if the font fails to load we don't render times), but this is unfortunately rather hard to fix.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
Emilio, is there a workaround to this issue?
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
You should specify a fallback font anyways (so that if the font fails to load we don't render times), but this is unfortunately rather hard to fix.
Why would the fallback font work if the primary one doesn't? It's not like the primary font is missing.
|
|
||
Comment 5•2 years ago
|
||
Well, the primary font is missing tho. Think of the select popup of an <iframe> without your custom CSS fonts loaded. It's not quite what's going on, but similar.
Right, so what will the fallback font fix in this instance? Wouldn't it also need to be propagated to the select popup <iframe>?
I guess, I don't understand why specifying Verdana font works perfectly (e.g. it is rendered in the dropdown), but ProximaNova-Regular does not.
If you look at the sample below, you'll see that Verdana shows up properly in the dropdown, but ProximaNova-Regular does not.
https://rgelb.github.io/ffsample/index.html
And the linked duplicate ticket in fact works fine. Click on the repro sample attached to it and you'll see.
Description
•