UI font incorrectly scaled after upgrade 130 -> 131 on linux
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: trondsg+bugzilla+mozilla, Unassigned)
Details
Attachments
(1 file)
|
24.76 KB,
image/png
|
Details |
firefox ui default settings.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0
Steps to reproduce:
Upgrade from 130 to 131.
Upgrade: firefox:amd64 (130.0+linuxmint1+una, 131.0+linuxmint1+una)
XFCE Custom DPI setting was already at 113.
Actual results:
After upgrade, where settings were already at
layout.css.devPixelsPerPx = -1
XFCE Custom DPI = 113
Firefox UI is far too big.
Websites are also scaled up.
Further, when changing layout.css.devPixelsPerPx to a lower value (0.8849557522123894) to compensate (for XFCE DPI set to 113), the font size in the Firefox UI, gets tiny. This means there is no workaround.
Either websites and chrome size are both large, but chrome font is normal,
or websites and chrome size are normal, but chrome font size is too small.
Note that turning off custom DPI in XFCE and setting devPixelsPerPx to 1, still leaves Firefox with smaller fonts than the native GTK UI.
Expected results:
No change from FF 130.
There should be no change in what Firefox considers the device dpi that isn't correctable by changing layout.css.devPixelsPerPx.
Firefox UI font size should match XFCE Appearance panel font size with either of the following settings combinations:
layout.css.devPixelsPerPx = -1.0
XFCE Custom DPI off.
or
layout.css.devPixelsPerPx = 100/custom_dpi
XFCE Custom DPI to some value
e.g.
layout.css.devPixelsPerPx = 0.8849557522123894
DPI = 113.
The font in question is Verdana 8. (GTK by default uses font sizes in pt, not pixels, as far as I could figure out.)
|
||
Comment 1•1 year 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.
|
Reporter | |
Comment 2•1 year ago
|
||
I tried the setting ui.textScaleFactor, which had to be created.
It does exactly the reverse of what is says: It changes the scale of everything, except for the text.
With the following settings, I was able to resolve my problem:
ui.textScaleFactor = 100
layout.css.devPixelsPerPx = -1.0
XFCE DPI = 113
However, this does not negate the fact that with the default settings of:
ui.textScaleFactor not set
layout.css.devPixelsPerPx = -1.0
No custom DPI in Xfce
The UI fonts are too small, and smaller than in XFCE.
(The letter A with Verdana Regular 8 is 7 px in FF, vs 8 px in XFCE.)
Surely this is a bug. Without customization, shouldn't FF use the OS setting for the UI font?
Related:
bug 1922556
bug 1211547
Btw, referring to a discussing in another bug, this DPI setting in XFCE, is under the tab Fonts in the Appearance control panel, and in XFCE only scales UI fonts, except for Chromium/Electron-based apps and similar.
|
|
Reporter | |
Comment 3•1 year ago
|
||
ui.textScaleFactor not set
layout.css.devPixelsPerPx = -1.0
No custom DPI in Xfce
|
||
Comment 4•1 year ago
|
||
This is an intended change. Before, Firefox didn't do anything with your 113 dpi, but now it does.
ui.textScaleFactor not set
layout.css.devPixelsPerPx = -1.0
No custom DPI in Xfce
It makes sense that with this your font is too small. If you don't set DPI, how would Firefox know how to scale?
Surely this is a bug. Without customization, shouldn't FF use the OS setting for the UI font?
Afaik, Firefox does not follow the OS setting for UI font, only the scale of the font. If you keep your DPI at the default 96, it'll most likely be too small then, as your real DPI should be 113.
By the way, this:
ui.textScaleFactor = 100
layout.css.devPixelsPerPx = -1.0
XFCE DPI = 113
is equal to this:
ui.textScaleFactor not set
layout.css.devPixelsPerPx = -1.0
XFCE DPI = 113
|
|
||
Comment 5•1 year ago
|
||
Sorry, I am mistaken, that last statement is false.
|
|
||
Comment 6•1 year ago
|
||
Okay, Firefox does use OS setting for the font indeed. But I don't understand why with
ui.textScaleFactor not set
layout.css.devPixelsPerPx = -1.0
No custom DPI in Xfce
your screenshot has a smaller font on Firefox then the rest. I can't reproduce that. Are you sure Xfce updated font size when you disabled custom DPI?
Also, with your preferred setting of
ui.textScaleFactor = 100
layout.css.devPixelsPerPx = -1.0
XFCE DPI = 113
Websites will actually render as if you had set 96 DPI. That is not really correct.
For example, I use a DPI of 115 effectively, and if I have a website using Cantarell 11pt, I get the same font size on the page as in my Firefox UI.
|
|
Reporter | |
Comment 7•1 year ago
|
||
Regarding intended change. This changes the size of things on the screen. Everything that changes the size of things, should be considered an accessibility-related change, and if reversible, a how-to should be in the release notes.
I am confirming a 1 px difference with no custom DPI and Verdana 8.
However, with other fonts and sizes, I don't have that difference. This points to a rounding error somewhere, rather than a bug in the algorithm. I wasn't expecting that when reporting the bug.
Further, the font rending in FF tabs and address bar are not using subpixel rendering. IMO this is a bug (and may be causing the 1 px size difference). XFCE/GTK and the websites in FF do use subpixel rendering.
I use a custom setting of:
Xft.antialias: 1
Xft.hinting: 1
Xft.hintstyle: hintfull
Xft.rgba: rgb
11-lcdfilter-light.conf
|
|
||
Comment 8•1 year ago
|
||
Regarding intended change. This changes the size of things on the screen.
As was mentioned in the other bugs you linked, this change is mostly considered a fix. For example, users with a dpi of 168 used to get a rounded dpi of 192; obviously too big. Then there are users like me who got a rounded down dpi. In essence, all the rounding got removed now, making it more consistent with every other GTK3 (also GTK4) app, which never round dpi. Just to add, literally any dpi value between 96 and 120 would get rounded to 96 before.
The change did get mentioned in the release notes now, but as ui.textScaleFactor is not really a properly supported setting (notice how it doesn't exist by default), I think mentioning that as a reversing option would be undesirable.
Further, the font rending in FF tabs and address bar are not using subpixel rendering. IMO this is a bug (and may be causing the 1 px size difference). XFCE/GTK and the websites in FF do use subpixel rendering.
That should be unrelated to the dpi handling change.
|
|
Reporter | |
Comment 9•1 year ago
|
||
GTK 3 apps don't round DPI for fonts. And thus not for widgets that are sized by the contents, when the contents is text, which is the case for most widgets. But apart from that, there seems to be rounding. Icons sizes don't change. Scrollbar width doesn't change for me (not sure if I have a custom setting). This is obviously the wrong behaviour, but it's what I'm seeing.
I know ui.textScaleFactor isn't supported, that's the problem. I have to hunt down unsupported settings for sizes and animations for almost every upgrade (they don't change for every version, but I wait long between upgrades to avoid this problem for as long as I can).
This decision that chrome and webpage client area are governed by the same settings (e.g. layout.css.devPixelsPerPx, prefersReducedMotion), is not practical, nor does it make sense. Seems to be an over-application of don't repeat yourself.
Btw, a custom dpi of 96, does not give the same result as not setting a custom dpi. Setting it to 95, does give the same result. I don't know why this is.
Should I report a separate bug for the lack of subpixel rendering?
|
|
||
Comment 10•1 year ago
|
||
Icons sizes don't change. Scrollbar width doesn't change for me (not sure if I have a custom setting).
For most things like these, GTK uses pixels, not points, so that they are independent of dpi makes sense :)
Btw, a custom dpi of 96, does not give the same result as not setting a custom dpi. Setting it to 95, does give the same result. I don't know why this is.
Huh. From the Firefox side of things, a dpi of 96 should give an exact 1.0 scale factor, so don't know what's going on there. Are you sure xrdb -query | grep dpi returns 96?
Should I report a separate bug for the lack of subpixel rendering?
Probably, yes, as I don't see a way it's related to the DPI changes.
|
|
Reporter | |
Comment 11•1 year ago
|
||
With a custom dpi of 96:
xrdb -query | grep dpi
Xft.dpi: 96
With no custom dpi, there is no output. Yet kerning changes in gtk apps, and the text in FF tabs is moved 1 px up.
I guess this bug can be closed.
|
|
||
Comment 12•1 year ago
|
||
Strange... And you haven't set the GDK_DPI_SCALE environment variable?
I agree this can be closed, but I don't have closing rights so feel free to do that yourself :)
|
||
Comment 13•1 year ago
•
|
||
Closing as not-a-Firefox-bug per last few comments (if I'm understanding them correctly).
Description
•