[mac] kBaseFonts: Osaka-Mono
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: thorin, Assigned: jfkthame)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
spin off from Bug 1720408
STR
- visit https://arkenfox.github.io/TZP/tests/fontlists.html
- flip RFP on
- run
min + RFP
test - not Osaka-Mono is detected
- see kBaseFonts: https://searchfox.org/mozilla-central/source/gfx/thebes/StandardFonts-macos.inc
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Osaka-Mono is a special case, as in the current macOS font configuration it is not really a font-family name in its own right (it's a face in the Osaka family, but not accessible as such via CSS font selection properties). We expose it as a separate family mostly for legacy reasons; it used to be a default font used on macOS, and some sites may explicitly request it.
This is handled via the font.single-face-list pref, which lists any such instances where a specific face is to be exposed as a separate family (currently Osaka-Mono is the only case). It turns out there are two bugs in how this is handled that affect the behavior here:
(a) the visibility attribute is not propagated from the Osaka family to its Osaka-Mono "child", so we don't have the correct visibility level for it; and
(b) if the font list gets reinitialized, we'll fail to set up Osaka-Mono at all in the new list because the strings in the mSingleFaceFonts array actually got munged the first time it was used.
(The latter was a regression from bug 1708768; prior to that, we just re-read the pref rather than stashing it in an array for future use.)
Assignee | ||
Comment 2•3 years ago
|
||
Updated•3 years ago
|
Comment 4•3 years ago
|
||
bugherder |
Description
•