Open Bug 1621915 Opened 5 years ago Updated 3 months ago

funky fonts in Flatpaks

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: mtabara, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

left_flatpak_right_Firefox
298.06 KB, image/png
Details
Left flatpak, right (less customized profile) Firefox from Mozilla
95 bytes, image/png
Details
facebook screenshot
603.61 KB, image/png
Details

:Mikaela reported this bug in Matrix with the following comment(s):

  • some fonts look unusual in Discourses and Bugzilla, but that may be expected with the flatpak not having propietary fonts or something?
  • we probably need to add some dependency but I can't promise that will make p11-kit happy
  • fonts available on the host are exposed to flatpak applications so as long as you have them installed, that shouldn't be the case

Will upload some images in a bit to show diffs between regular Firefox and flatpak Firefox.

The left one is the flatpak, the right one is 74.0 (64-bittinen) from https://releases.mozilla.org/pub/firefox/releases/ (with heavy customization I guess, so maybe this is user error). Mikaela says she's not sure how accurate the screenshot shows the differences.

Summary: funcky fonts in Flatpaks → funky fonts in Flatpaks

I noticed that a screenshot of GitHub may show the difference in the fonts more clearly. The difference seems less defined in a screenshot that on the screen though.

Depends on: 1441922

Related discussion in Flatpak github: https://github.com/flatpak/flatpak/issues/2861

Apparently adding this to ~/.var/app/org.mozilla.firefox/config/fontconfig/fonts.conf helps:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <!-- Disable bitmap fonts. -->
    <selectfont><rejectfont><pattern>
        <patelt name="scalable"><bool>false</bool></patelt>
    </pattern></rejectfont></selectfont>
</fontconfig>

I don't understand this font stuff too well, but to me disabling bitmap fonts sounds more like a workaround rather than a proper fix. However looks like bitmap fonts specifically are affected.

This is how Flatpak Firefox renders github fonts on Debian 10:

https://seestieto.com/misc/bugs/FF-font-Flatpak.png

Vs. rendering on standard Debian Firefox:

https://seestieto.com/misc/bugs/FF-font-Debian.png

No longer depends on: 1441922

Going forward, Flatpak-related bugs will no longer be filed under RelEng, but instead in Core/Widget:GTK where folks have much more indepth knowledge on this. If the issues are RelEng related, they can be filed against Release Engineering :: Release Automation: Other and we'll take care of that.

Component: Release Automation: Flatpak → Widget: Gtk
Product: Release Engineering → Core
Target Milestone: --- → Future
See Also: → 1714318
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3

I seem to be affected now particularly severely by a variation of this issue in Debian 11 Bullseye and org.mozilla.firefox version 112.0: fonts in most GitHub content pages (frontpage exluded) were invisible.

The same workaround for ~/.var/app/org.mozilla.firefox/config/fontconfig/fonts.conf fixed the issue for me.

I suppose I have some bitmap font installed that somehow gets selected but doesn't actually render anything in this case.

(In reply to flux-github from comment #5)

I seem to be affected now particularly severely by a variation of this issue in Debian 11 Bullseye and org.mozilla.firefox version 112.0: fonts in most GitHub content pages (frontpage exluded) were invisible.

That sounds like bug 1827950, recently fixed in Nightly (and coming to Beta soon).

I can confirm that this bug is still reproducible with:
Debian 12 + Firefox 115.0.2 (mozilla-flatpak)

Affected font: Helvetica
(which is an alias to Nimbus Sans)

$ fc-match Helvetica
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"

How to reproduce:
Create sample html file and set font-family to "Helvetica".

<html>
  <head>
    <style>
      body { font-family: Helvetica; }
    </style>
  </head>
  <body>
    <h1>
      Lorem ipsum
    </h1>
    <p>
      Lorem ipsum dolor sit amet...
    </p>
  </body>
</html>

In a real world this issue is visible at Facebook website

Workaround:
create "fonts.conf" as mentioned in the comment #3

Duplicate of this bug: 1851493
Duplicate of this bug: 1629811
Duplicate of this bug: 1879491
Duplicate of this bug: 1839721
Attached image facebook screenshot —

I have installed the flatpak version (FF 130.0). Facebook looks terrible.

And I do not see any ~/.var/app/org.mozilla.firefox/config/fontconfig/fonts.conf in flatpak folder. Actually there is no /fontconfig/ folder at all..

Try creating the file yourself. Does that work?

Yes, manually adding folder /fontconfig and the file to ~/.var/app/org.mozilla.firefox/config/fontconfig/fonts.conf fixed for me the font problem.

Strange, after 5 years it is still not fixed... :-/

Still not fixed with FF 136 flatpak (openSUSE Tumbleweed). How should Linux gain market share with such problems? :(

It's not a Linux problem : it's a Flatpak issue.

See https://en.opensuse.org/Firefox for OpenSuse

But who is making the flatpak. Firefox team I assume, not the flatpak portal.

Hi. I used Gemini 2.5 / Deep Research to investigate this problem. Here is its summary of our findings:

It's understood that Mozilla utilizes a distinct process for packaging the official Firefox Flatpak, involving an internal mach repackage flatpak command and pushing pre-built artifacts to Flathub, rather than a typical source-based build directly on Flathub's infrastructure. The org.mozilla.firefox.BaseApp provides shared dependencies.

Analysis of a script representative of this packaging logic (python/mozbuild/mozbuild/repackaging/flatpak.py) shows the specific sandbox permissions being set during the flatpak build-finish stage.

The key finding is that the flatpak build-finish command in the analyzed packaging script does not grant the Firefox Flatpak explicit filesystem access to standard host fontconfig configuration directories. Specifically, permissions such as:

  • --filesystem=/etc/fonts:ro (or more targetedly /etc/fonts/conf.d:ro and /etc/fonts/fonts.conf:ro)
  • --filesystem=xdg-config/fontconfig:ro (for user-specific fontconfig settings)

appear to be absent from the list of arguments passed to flatpak build-finish.

Consequences of Missing Permissions:

Without these permissions, the fontconfig instance running within the Firefox Flatpak sandbox cannot access the host system's (and user's) fontconfig rules. These rules often include critical configurations such as:

  • Disabling or deprioritizing bitmap fonts (e.g., via 70-no-bitmaps.conf).
  • Aliasing preferences.
  • Specific hinting and anti-aliasing defaults.

As a result, the sandboxed fontconfig likely falls back to the default rules provided by the org.freedesktop.Platform runtime, which may be too minimal and can lead to the selection of undesirable bitmap fonts for certain CSS generic families or specific font names, causing the reported poor rendering.

This directly explains why user-provided workarounds are effective:

  • Copying /etc/fonts/conf.d/*.conf into ~/.var/app/org.mozilla.firefox/config/fontconfig/conf.d/.
  • Creating a custom fonts.conf in ~/.var/app/org.mozilla.firefox/config/fontconfig/ to explicitly reject bitmap fonts.
    These workarounds manually supply the necessary fontconfig rules directly within the Flatpak's accessible environment.

Proposed Non-Workaround Solution:

A potential systemic solution would be to modify Mozilla's Flatpak packaging script to include the appropriate read-only filesystem permissions for host fontconfig directories in the flatpak build-finish command. For example:

  • --filesystem=/etc/fonts:ro
  • --filesystem=xdg-config/fontconfig:ro
  • Optionally, --filesystem=xdg-data/fonts:ro for user-installed fonts.

Granting these permissions would allow the Firefox Flatpak to respect system-wide and user-specific font configurations, likely resolving these persistent font rendering issues by enabling fontconfig to make more appropriate font selections.

This would align the Firefox Flatpak's font rendering behavior more closely with that of natively installed Firefox and other applications on the user's system.

We hope this analysis is helpful in pinpointing and addressing the root cause of this issue.

(In reply to Derek V. Schmalenberger from comment #18)

Hi. I used Gemini 2.5 / Deep Research to investigate this problem. Here is its summary of our findings:

Have you (or another human) confirmed that Firefox's build process produces a manifest more restrictive than flatpaks built using the more standard process?

If you haven't checked, I'd advise that the Firefox devs consider this to just be more A.I. spam.

If you have and you've confirmed this, then the solution is a patch to make Firefox manually do whatever the standard process produces.

If you have but Firefox is not uniquely problematic, then I'd suggest the bug is actually in Flatpak and may be related to one of these:

After further testing, I found that simply granting the Firefox Flatpak access to host font configuration directories (e.g., via flatpak override --user --filesystem=/etc/fonts:ro org.mozilla.firefox and --filesystem=xdg-config/fontconfig:ro) did not resolve the Helvetica rendering issue on its own. This appears to be because, without specific user-defined rules in those locations that address the problem, the Flatpak still defaults to problematic font choices. However, enabling this access does allow a user-defined fontconfig rule (like one rejecting non-scalable fonts, if placed in ~/.config/fontconfig/conf.d/) to become effective for the Flatpak.

A hopefuly useful finding from my investigation is that fc-match Helvetica executed inside the Firefox Flatpak sandbox (even with the aforementioned overrides) resolves to helvR12-ISO8859-1.pcf.gz. This is a bitmap PCF font, which explains the non-anti-aliased appearance. This behavior differs from the host system, where "Helvetica" correctly resolves to the scalable font LiberationSans-Regular.ttf.

A possible solution would be to have Firefox's script add the fontconfig rule (e.g., <selectfont><rejectfont><pattern><patelt name="scalable"><bool>false</bool></patelt></pattern></rejectfont></selectfont>) to /app/etc/fonts/conf.d/ within the Flatpak's filesystem structure.

After about 18 hours of investigating how to eliminate this bug (I'm not exaggerating), I'm happy to say that by reporting it to both freedesktop-sdk and fontconfig, I've helped bring the relevant developers' attention together to hopefully solve this problem.

It turns out that a solution (70-no-bitmaps.conf) was lying dormant in /etc/fonts/conf.avail. It simply needed to be copied or linked to /etc/fonts/conf.d, but the freedesktop-sdk developers have a policy to not change the defaults. Now, one of the fontconfig developers has agreed to make it happen upstream.

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/474

That's great -- as that change propagates to distros and users, I think it will improve things for a bunch of cases. Thanks for pursuing it!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: