Closed Bug 1781613 Opened 2 years ago Closed 2 years ago

[Regression] Firefox-103 UI fonts larger than defined in gtk settings.ini

Categories

(Core :: Widget: Gtk, defect)

Firefox 103
Unspecified
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- unaffected
firefox103 --- wontfix
firefox104 --- wontfix
firefox105 --- wontfix

People

(Reporter: andrem, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

Update to firefox-103.0

Actual results:

UI fonts (Fonts on tabs and other UI elements) got quite a bit bigger than the font defined in gtk's settings.ini. Now the firefox UI text displays much larger than in other gtk apps (geeqie, diffuse...), resulting in an incoherent desktop experience.

This machine uses gtk on X, just a window manager, no desktop environment,
and has a rather high dpi display (Chromebook Pixel). Changing the gtk
font size from 16 to 10 gets firefox to look more or less like before, only with
smaller URL bar text. But that leaves other gtk applications with a way too small UI font, so that doesn't help.

This looks to be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1773342, also perhaps https://bugzilla.mozilla.org/show_bug.cgi?id=1773823

Expected results:

UI fonts should not be scaled to larger size, but keep interpreting the gtk settings as other gtk applications do.

Component: Untriaged → Widget: Gtk
OS: Unspecified → Linux
Product: Firefox → Core

This appears to be related to the following discussion on the Mozilla Connect forum. The change in FF 103 regarding how it works with the windows DPI and text size settings has created a huge mess. Users are not happy! Adding the setting for ui.textScaleFactor to about:config and using a number of 100 seems to have worked for many of us, but the point is we should not have needed to add this setting in the first place. Some users have reverted to FF 102 and some say they are switching to a different browser. This is something which desperately needs to be fixed! https://connect.mozilla.org/t5/discussions/windows-quot-make-text-bigger-quot-accessibility-setting/td-p/10639

Thanks for the pointer!

While the hubub seems centered around the windows change, which is supposed to make behaviour consistent with linux, it ironically also breaks Linux GTK desktop conventions now.

I do believe firefox now takes the X dpi setting into account. My desktop is running with

xrandr --dpi 144

This setting is used by xaw for xterm and fluxbox and by mpv, if I remember right (didn't test).

Hidpi behaviour for gtk was discussed heatedly way back when, but thankfully it settled to consistent behaviour, I just need to use a laarge (16pt) UI font, and all's fine for all gtk apps.

Firefox now applying the scale factor looks fine to me by itself, I actually work around this issue with a dedicated user that uses gtk's default font size (11) for running firefox.

The real problem from my point of view is incompatibility with thunderbird until the 102 branch goes EOL and then both diverging indefinitely from any other gtk app I use.

Apart from this, this may be resolved WORKSFORME if the view taken in https://bugzilla.mozilla.org/show_bug.cgi?id=1782287 persists.

Thank you for the link to the Windows bug. I did not find that one when I searched; I only found this one, and I didn't pay attention to see that your bug is about Linux OS. I will repost my comment there.

Yes, thanks for helping here.

I was hit with this after an update today to Firefox 103.0.2.

I am using Linux (Debian 11) on a Thinkpad 6 with 2560 x 1440.

Today all the web pages start HUGE, and the menus and UI fonts are also massive.

I set "ui.textScaleFactor" to 100 and things look better but I still have to use a day and see how things go. It seems wrong to have to create and set this "config" param suddenly and I fear future trouble. This sort of breakage is painful.

Sorry - I meant Thinkpad X1 rev 6.

An update: in my assessment above in Comment 2, I didn't realize that on hidpi screens, the firefox UI is at odds with any GTK dialog boxes it spawns, e.g. the save dialog.

Thus, firefox doesn't provide a consistent (linux?) UI on hidpi screens anymore, at all.

The suggestion to work around this using ui.textScaleFactor does not work for me either: The UI font in tabs etc. is rendered a lot bigger than in any GTK dialog, with any setting (I tried 67, 100, 133). The only way I seem to arrive at the intended font size seems to be the change in GTK settings, with the side-effects of a way-too-small small font in GTK dialogs and incompatibility with any GTK app.

This contradicts the changes' intentions. Please re-evaluate.

Set release status flags based on info from the regressing bug 1773342

:emilio, since you are the author of the regressor, bug 1773342, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

Yeah this is not the same as the Windows text zoom changes. Linux behaved like that already before-hand (that change made Windows behave like Linux, actually).

Can you paste your gtk settings? Does this reproduce in a clean profile? I think you might be overriding layout.css.devPixelsPerPx in about:config, and its behavior did change a bit with regards to system fonts in bug 1773823. See bug 1777902 for discussion about how to get the previous behavior exactly, if that's what you want.

Flags: needinfo?(emilio) → needinfo?(andrem)
See Also: → 1777902

Also, can you paste the result of running window.devicePixelRatio on an unzoomed page, ideally in both 102 and 103? That can get us the system text zoom value.

You can launch older versions of Firefox by running:

$ pip3 install --user mozregression
$ mozregression --launch 102

From your terminal.

Ah, sorry, should've read the whole thread rather than just comment 0. Given comment 2 I think this is working as intended. You can get the previous behavior with a mix of ui.textScaleFactor and layout.css.devPixelsPerPx, if you need to. I agree it being incompatible with Thunderbird might be a bit annoying.

That series of patches could be upliftable to ESR if needed, should apply cleanly I think, but it's a bit too risky for my taste IMO. Magnus / Ryan, if you want I can try to get an upliftable roll-up patch with all the relevant fixes. Let me know.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(ryanvm)
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(andrem)
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME

Ah yes, I had layout.css.devPixelsPerPx set to 1.5. Unsetting the variable gets the font sizes back into the right ballpark for the base UI, so the ff UI and spawned gtk windows look about the same size. I'm still struggling somewhat to find good zoom and text size defaults for webpages again, but hey :) So thank you!

That said: text in plugin UIs and the dev tools is coming up tiny after unsetting layout.css.devPixelsPerPx. I tried this in a fresh profile as well as my default one.
I guess I will open a new bug for that, but I need to research this first. I'm drowning a bit in moving parts right now, tbh.

My gtk settings.ini:
[Settings]
gtk-theme-name = Adwaita
gtk-icon-theme-name = Adwaita
gtk-cursor-theme-name = Adwaita
gtk-font-name = Liberation Sans 16

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
If I understand the issue correctly, sounds indeed a bit risky as it might upset some users.

Flags: needinfo?(mkmelin+mozilla)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

That series of patches could be upliftable to ESR if needed, should apply cleanly I think, but it's a bit too risky for my taste IMO. Magnus / Ryan, if you want I can try to get an upliftable roll-up patch with all the relevant fixes. Let me know.

I'm not crazy at all about uplifting those changes to ESR.

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