Closed Bug 2051021 Opened 3 months ago Closed 2 months ago

Fontconfig 2.18 regression breaks font matching for fonts with special characters (-:,)

Categories

(Core :: Layout: Text and Fonts, defect)

Firefox 152
defect

Tracking

()

RESOLVED FIXED
154 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox-esr140 --- wontfix
firefox152 --- wontfix
firefox153 --- fixed
firefox154 --- fixed

People

(Reporter: aldelaro5, Assigned: emilio, NeedInfo)

References

Details

Attachments

(4 files)

Attached file FOT-PopJoyStd-B.otf —

Steps to reproduce:

  1. Download the attached .otf file containing a font and install it on the system so Firefox can locate it.
  2. 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.

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.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

Which operating system are you running Firefox on?

Flags: needinfo?(aldelaro5)

(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.

Flags: needinfo?(aldelaro5)

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)

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?

Flags: needinfo?(emilio) → needinfo?(aldelaro5)

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.

Flags: needinfo?(jfkthame)

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?

fc-match "FOT\-PopJoy Std" does also work on Fontconfig 1.18... Jonathan should we be escaping the dashes manually I guess?

There shouldn't be any need to escape dashes, AFAIK -- this sounds like a fontconfig bug. I'll try to dig around a bit....

Flags: needinfo?(jfkthame)

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.

Yeah, that looks pretty suspicious. Doesn't look like this was an intentional behavior change, it's an FC regression.

I confirmed that manually escaping it works around the issue.

I'll send a fix upstream.

(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.

Summary: Broken font rendering regression since Firefox 150 for specific fonts → Fontconfig 2.18 regression breaks font matching for fonts with special characters (-:,)
Assignee: nobody → emilio
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Fontconfig 2.12 was released in 2017. We can probably remove this now.

This presumably affects all versions when running on a system with the fontconfig bug, so probably worth uplifting the workaround wherever possible.

(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,Regular

So 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.

Flags: needinfo?(aldelaro5)
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 154 Branch

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)

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
Attachment #9605702 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [uplift][qa-ver-needed-c154/b153]
Attachment #9605702 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

This could probably use an ESR140 uplift request also.

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.

Flags: needinfo?(emilio) → needinfo?(ryanvm)

Fair enough. We can hold off for now and only worry about it if we start getting complaints later down the line.

Flags: needinfo?(ryanvm)

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

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).

Flags: needinfo?(aldelaro5)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: