Logs page renders blank when LANG is a CJK locale on Flatpak (monospace resolves to proportional Noto Sans CJK)

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#8,107 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust, typescript
Bereich
desktop, frontend

Rechercherichtung

Beginne mit packages/ui/src/composables/terminal.ts, wo der Issue zufolge das Terminal seine Schriftfamilie auf das generische monospace setzt; prüfe, wie die Logs-Seite xterm.js konfiguriert und ob benachbarte Tests das Rendern des Terminals abdecken. Reproduziere das Problem mit einem CJK-LANG in Flatpak und vergleiche es mit en_US.UTF-8. Fertig ist die Aufgabe, wenn Logs und der leere Zustand unter einem CJK-Locale gerendert werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Please confirm the following
  • I checked the existing issues for duplicate problems
  • I have tried resolving the issue using the support portal
  • I have ensured my Modrinth App installation is up to date
What version of the Modrinth App are you using?

0.22.0 (Flathub, com.modrinth.ModrinthApp, runtime org.gnome.Platform/x86_64/49)

What operating systems are you seeing the problem on?

Linux — Fedora 44, KDE Plasma (Wayland), system locale zh_CN.UTF-8

Describe the bug

When the system/process locale is Chinese (LANG=zh_CN.UTF-8), the instance Logs page renders an entirely blank terminal, even though the logs are read successfully.

The page chrome (search box, level filters, log-source dropdown) works, and the dropdown correctly lists latest.log, crash reports, and rotated .log.gz files. Selecting any of them still leaves the terminal blank. The empty-state message/frog does not appear either, which suggests the xterm.js terminal never renders any text.

Launching the same Flatpak with LANG=en_US.UTF-8 makes the Logs page work normally, so the data/back-end side is fine — this is a rendering issue.

The same instance shows:

  • LANG=zh_CN.UTF-8: an empty white terminal area
Image
  • LANG=en_US.UTF-8: empty-state bubble and log contents render normally
Image
Steps to reproduce
  1. Use a system with LANG=zh_CN.UTF-8 (or any CJK locale), and install Modrinth App from Flathub.
  2. Open an instance that has logs (or launch the instance once so logs exist).
  3. Go to the instance Logs tab.
  4. Observe that the terminal area is completely blank, including no empty-state text.

Optional control:

flatpak run --env=LANG=en_US.UTF-8 com.modrinth.ModrinthApp

→ the Logs page renders correctly.

Expected behavior

The Logs page should display the live log / selected log file regardless of the system locale.

Additional context / root cause analysis

Inside the Flatpak sandbox, fontconfig resolves the generic monospace family differently depending on locale:

$ flatpak run --command=sh com.modrinth.ModrinthApp -c \
    'LANG=en_US.UTF-8 fc-match monospace; LANG=zh_CN.UTF-8 fc-match monospace'
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
NotoSansCJK-VF.ttc: "Noto Sans CJK SC" "Regular"

Noto Sans CJK SC is a proportional CJK font, not a monospace font. The console component hard-codes the generic family:

// packages/ui/src/composables/terminal.ts (v0.22.0)
fontFamily: 'monospace',

xterm.js requires a monospace font for its character-width measurement. When the generic monospace alias resolves to a proportional (and variable) CJK font, the terminal produces no visible output at all — not even the empty-state bubble.

Note that the actual monospace CJK font is present in the sandbox (fc-list shows Noto Sans Mono CJK SC); fontconfig just prefers the proportional Noto Sans CJK SC under zh_CN.

Workaround (app-local, does not affect other apps):

Create ~/.var/app/com.modrinth.ModrinthApp/config/fontconfig/fonts.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<fontconfig>
  <match target="pattern">
    <test qual="any" name="family"><string>monospace</string></test>
    <edit name="family" mode="prepend" binding="strong">
      <string>DejaVu Sans Mono</string>
    </edit>
  </match>
</fontconfig>

After this, LANG=zh_CN.UTF-8 fc-match monospace inside the sandbox returns DejaVu Sans Mono and the Logs page renders again (CJK characters fall back to Noto CJK automatically).

Suggested fix: don't rely on the bare generic monospace alias for the terminal. Use an explicit monospace stack, e.g.

fontFamily: "'DejaVu Sans Mono', 'Noto Sans Mono', 'Noto Sans Mono CJK SC', 'Liberation Mono', monospace",

and/or ship a known monospace font with the app. It may also be worth checking whether xterm.js needs a guard against a resolved proportional font.

Vorherrschende Sprache
Rust
Sterne
2.5k
Forks
663
Ø Merge
2 T. 11 Std.
Gemergte PRs (30 T.)
122

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modrinth/code

Alle Issues in modrinth/code

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.