Fontconfig 2.18 regression breaks font matching for fonts with special characters (-:,)
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: aldelaro5, Assigned: emilio, NeedInfo)
References
Details
Attachments
(4 files)
Steps to reproduce:
- Download the attached .otf file containing a font and install it on the system so Firefox can locate it.
- Go into Settings -> Accessibility section, Font Family field and select "FOT-PopJoy Std".
Actual results:
The font of the browser did not change on Firefox 152, but it did on Firefox 150. I have not tested Firefox 151.
Expected results:
The browser font should have changed. It is the only font I have where I can reproduce the issue, other fonts seems to work.
Comment 1•3 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 months ago
|
||
Which operating system are you running Firefox on?
(In reply to Jonathan Kew [:jfkthame] from comment #2)
Which operating system are you running Firefox on?
Arch Linux, I had just updated all my packages so I went from 150 to 152 and that's where I started to notice the regression.
Comment 4•2 months ago
|
||
The severity field is not set for this bug.
:emilio, could you have a look please?
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 5•2 months ago
|
||
I can reproduce but it doesn't seem like a Firefox regression. It seems like a fontconfig regression. I can reproduce on older firefox as well, including 150.
$ fc-match "FOT-PopJoy Std"
NotoSans-Regular.ttf: "Noto Sans" "Regular"
$ fc-list | rg Std
/home/emilio/.local/share/fonts/FOT-PopJoyStd-B.otf: FOT-PopJoy Std,FOT-Popジョイ Std,FOT-PopJoy Std B,FOT-Popジョイ Std B:style=B,Regular
So it seems fontconfig is struggling with that font somehow? reporter, do you agree this doesn't seem like a Firefox issue?
| Assignee | ||
Comment 6•2 months ago
|
||
Jonathan given the above do you have any other diagnostics? I've tried to fc-match with the font PSName or so and doesn't help either... Any suggestions? Otherwise we should just report this to fontconfig.
| Assignee | ||
Comment 7•2 months ago
|
||
I confirmed that downgrading fontconfig with:
pacman -U https://archive.archlinux.org/packages/f/fontconfig/fontconfig-2%3A2.17.1-1-x86_64.pkg.tar.zst
Fixes the issue and works both in 150 and nightly but:
$ fc-match "FOT-PopJoy Std"
NotoSans-Regular.ttf: "Noto Sans" "Regular"
$ fc-list | rg Std
/home/emilio/.local/share/fonts/FOT-PopJoyStd-B.otf: FOT\-PopJoy Std,FOT\-Popジョイ Std,FOT\-PopJoy Std B,FOT\-Popジョイ Std B:style=B,Regular
$ fc-match "FOT\-PopJoy Std"
FOT-PopJoyStd-B.otf: "FOT-PopJoy Std" "B"
Note the escapes. I'm not familiar with the escape syntax, tho... Let me try fc-match with the escaped - on fontconfig 1.18 I guess?
| Assignee | ||
Comment 8•2 months ago
|
||
fc-match "FOT\-PopJoy Std" does also work on Fontconfig 1.18... Jonathan should we be escaping the dashes manually I guess?
Comment 9•2 months ago
|
||
There shouldn't be any need to escape dashes, AFAIK -- this sounds like a fontconfig bug. I'll try to dig around a bit....
| Assignee | ||
Comment 10•2 months ago
|
||
I was doing some digging, I think the root cause is that https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/7643efb77552076b035d3eb506ca836ed4764ca5 broke FcNameUnparse. FcNameUnparseValue dropped the escape argument.
Comment 11•2 months ago
|
||
Yeah, that looks pretty suspicious. Doesn't look like this was an intentional behavior change, it's an FC regression.
| Assignee | ||
Comment 12•2 months ago
|
||
I confirmed that manually escaping it works around the issue.
Comment 14•2 months ago
|
||
(In reply to Emilio Cobos Álvarez [:emilio] from comment #12)
I confirmed that manually escaping it works around the issue.
Sad, but I guess we'd better do that to mitigate the issue for users, as fontconfig doesn't necessarily update very quickly.
| Assignee | ||
Comment 15•2 months ago
|
||
| Assignee | ||
Updated•2 months ago
|
| Assignee | ||
Comment 16•2 months ago
|
||
Updated•2 months ago
|
| Assignee | ||
Comment 17•2 months ago
|
||
Fontconfig 2.12 was released in 2017. We can probably remove this now.
Comment 18•2 months ago
|
||
Comment 19•2 months ago
|
||
This presumably affects all versions when running on a system with the fontconfig bug, so probably worth uplifting the workaround wherever possible.
| Reporter | ||
Comment 20•2 months ago
|
||
(In reply to Emilio Cobos Álvarez [:emilio] from comment #5)
I can reproduce but it doesn't seem like a Firefox regression. It seems like a fontconfig regression. I can reproduce on older firefox as well, including 150.
$ fc-match "FOT-PopJoy Std" NotoSans-Regular.ttf: "Noto Sans" "Regular"$ fc-list | rg Std /home/emilio/.local/share/fonts/FOT-PopJoyStd-B.otf: FOT-PopJoy Std,FOT-Popジョイ Std,FOT-PopJoy Std B,FOT-Popジョイ Std B:style=B,RegularSo it seems fontconfig is struggling with that font somehow? reporter, do you agree this doesn't seem like a Firefox issue?
It indeed does seem to be a fontconfig issue, I can reproduce the problem and the escape workaround on my system.
Comment 21•2 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4bf4a7c25934
https://hg.mozilla.org/mozilla-central/rev/2364a96c6095
Comment 22•2 months ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox153towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Updated•2 months ago
|
Comment 23•2 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined/Reason for urgency: Work around fontconfig regression
- Code covered by automated testing?: no
- Fix verified in Nightly?: yes
- Needs manual QE testing?: yes
- Steps to reproduce for manual QE testing: Comment 0
- Risk associated with taking this patch: low
- Explanation of risk level: Relatively targeted fix.
- String changes made/needed?: none
- Is Android affected?: no
| Assignee | ||
Comment 24•2 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D310801
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 25•2 months ago
|
||
| uplift | ||
Comment 26•2 months ago
|
||
This could probably use an ESR140 uplift request also.
| Assignee | ||
Comment 27•2 months ago
|
||
I was thinking that given ESR153 is coming up, the intersection of folks using very recent fontconfig with ESR140 is unlikely to be very big, but let me know if you disagree?
https://pkgs.org/search/?q=fontconfig seems to hint that only Arch Linux / RawHide / other rolling distros have 2.18 right now.
Comment 28•2 months ago
|
||
Fair enough. We can hold off for now and only worry about it if we start getting complaints later down the line.
| Assignee | ||
Comment 29•2 months ago
|
||
Also the fix has been already released as part of 2.18.2: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/545
So unlikely any other distro will hit this
Comment 30•2 months ago
|
||
Hello, aldelaro! Can you please check if this bug is fixed on your end with latest Beta 154 and Release 153?
I was not able to repro the issue described in comment 0, using Ubuntu 26 or Arch Linux, on an affected Nightly build (2026-06-27).
Description
•