Flatpak/Linux: Font rendering completely broken for certain sites since v112
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: m, Unassigned)
References
Details
Attachments
(1 file)
27.31 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Steps to reproduce:
Font rendering is completely broken since version 112 for certain sites. (See screenshot)
Some sites showing the effect are:
https://www.mikrocontroller.net/
https://minkorrekt.de/
https://wrint.de/
But there are more sites showing this effect.
I think only the Flatpak version is affected and I think it only happens on Linux.
Using a new clean profile does not fix the problem.
Workaround:
If I untick the option "Allow pages to choose their own fonts, instead of your selections above" in the "Advanced" font settings, then fonts are rendered and the site is usable again.
Affected versions: 112 and 112.0.1.
I use Debian Unstable and Debian Stable as operating systems. Both are affected.
Actual results:
Fonts are not rendered at all.
Expected results:
Fonts shall be rendered.
Comment 1•2 years 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 years ago
|
||
This is almost certainly bug 1827950. Does it work as expected if you try a current Nightly release? (https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly)
Reporter | ||
Comment 3•2 years ago
|
||
The firefox-112.0.1.tar.bz2 release is not affected (I just tried that to verify).
Only the flatpak build is affected for me.
Therefore, testing the nightly tarball is not a valid test, IMO.
Is there a nightly-flatpak?
Comment 4•2 years ago
|
||
I'm afraid I don't know of a nightly-flatpak build, or how to create one (maybe it exists, but I'm unaware...)
Whether it's affected will depend what fonts it's trying to use; the flatpak vs non-flatpak versions probably get different font configurations. Specifically, the problem affects bitmap fonts (and probably legacy Type 1 postscript, I think), but not TrueType/OpenType fonts.
So I suspect your flatpak build is configured to use bitmap fonts (e.g. old X11 versions of Helvetica etc) as its defaults, and those are failing. You might be able to reproduce the problem with a non-flatpak version by configuring its fonts similarly.
Sorry I can't be more specific, but I don't really know anything about the flatpak environment or how it's configured.
Reporter | ||
Comment 5•2 years ago
|
||
Is this fix going to land in a 112.x.y bug fix release?
If so, then I think the simplest way would be to wait.
Comment 6•2 years ago
|
||
I hope it will appear in a 112.x bug-fix release, but that's ultimately up to the release managers to determine. It's definitely on track for v113.0 (currently in Beta), but I don't know if there are flatpak versions of beta releases.
Reporter | ||
Comment 7•2 years ago
|
||
I would strongly vote for getting it into 112.x, because otherwise the flatpak would be severely broken for the duration of a whole major release cycle. Alternatively, we could have some kind of font configuration change that makes the flatpak behave more like the tarball, if we don't want to have the full fix in 112.x.
Reporter | ||
Comment 8•2 years ago
|
||
I think the latest flatpak release 112.0.2 fixed the problem.
I can't reproduce it anymore.
Thanks for fixing it!
Updated•2 years ago
|
Description
•