1336558 - Tab and location bar text do not scale with layout.css.devPixelsPerPx on Linux

Status: RESOLVED WONTFIX

(Core :: Widget: Gtk, defect)

Description

[Michael Cooper [:mythmon]]

When changing layout.css.devPixelsPerPx, all of the UI changes size, except the text in the location bar and the text on tabs.

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

What operating system + version, Firefox version, e10s enabled or not?

This works as expected (both locationbar and tab titles) here on Windows 8.1 with Firefox 51.0.1 32-bit and e10s disabled and 54.0a1 20170205 32-bit with e10s enabled

Comment 2

[Michael Cooper [:mythmon]]

This doesn't work for me on Linux with Firefox 51.0.1 64-bit and e10s enabled.

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Confirmed, both with Firefox 51.0.1 and 54.0a1 in Xubuntu tab titles and the location bar content has an unchanged size. Has this ever worked? The builds from 2015 and 2016 I tried were also affected.

Comment 4

[:Gijs (he/him)]

This seems to be a GTK issue - global.css defines font: message-box for the window, and that's what we're using for these (and many other) labels. This is apparently what's causing the very small font size. Karl / Martin, any idea what's causing this? It would be helpful if font sizes did respect this pref, when testing hidpi styling without a hidpi machine.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Yes, looks like we don't scale Gtk elements. It also affects buttons on the webpage for instance.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Looks like we may use nsScreenGtk::GetDPIScale() in GetSystemFontInfo() instead of nsScreenGtk::GetGtkMonitorScaleFactor() and so on other places. But it suspect it's not so easy.

Comment 7

[Karl Tomlinson (:karlt)]

This behaviour would have been intentional.
layout.css.devPixelsPerPx defines the size of a CSS pixel.
System fonts such as message-box are the size of system
fonts, regardless of the size of the CSS pixel.

I recognise that testing hidpi situations would be useful, but scaling system
fonts would break the use case where users already have the correct system
font size but want to change the default size at which web pages render.

GDK_SCALE=<N> in the environment can test for integer scales <N>.
Testing non-integer scales can be done with something like GDK_DPI_SCALE=1.5
in the environment.

Comment 9

[forkest]

Why isn't this implemented on Linux in the same way it is done on Windows and macOS?

Where layout.css.devPixelsPerPx in its default -1 state honors system-wide scaling setting and zooms everything (web content and UI) according to it. Then the user may change the value to 1.0 for example if he wants to disable the scaling. Or to the scale level he wants.

At the same time on Linux the property does control scaling of everything, including web content and UI elements, but not the font size in those UI elements - fonts are scaled according to the GDK SCALE variables (expected default for the -1 value of the pref), but can't be controlled further: when you try to "undo" or change the scale using the preference, the UI elements change their size, but fonts inside them do not. And this is ugly as hell. And not desired behavior, obviously. I can't understand why don't you see it as a bug, especially considering the inconsistency between buggy Linux behavior and expected Windows/macOS one. If you stand for "the preference is for web content only", then make it really web content only and stop scaling the UI entirely (but this way it will still be inconsistent with other platforms), whereas now it scales web content and part of the interface and it is essentially broken.

Comment 10

[Karl Tomlinson (:karlt)]

(In reply to forkest from comment #9)

Why isn't this implemented on Linux in the same way it is done on Windows and macOS?

https://bugzilla.mozilla.org/show_bug.cgi?id=852963 tracks the bug on NT, and has not been fixed.

I don't know the story on MacOS.

At the same time on Linux the property does control scaling of everything, including web content and UI elements, but not the font size in those UI elements - fonts are scaled according to the GDK SCALE variables (expected default for the -1 value of the pref), but can't be controlled further: when you try to "undo" or change the scale using the preference, the UI elements change their size, but fonts inside them do not.

GDK_SCALE changes the size of GDK pixels and so affects system/GTK font sizes.
It is also used by Firefox in determining a default CSS pixel size.
layout.css.devPixelsPerPx is a different control.

And this is ugly as hell. And not desired behavior, obviously. [...] If you stand for "the preference is for web content only", then make it really web content only and stop scaling the UI entirely (but this way it will still be inconsistent with other platforms), whereas now it scales web content and part of the interface and it is essentially broken.

Firefox UI is choosing system font sizes but sizing elements containing text in CSS pixels. The behavior you see is the result of that choice.

Text elements in the UI and even icons could be sized in em or ex units for consistency with the fonts used. That may be a bug worth filing, but it is not the change requested in this report or in bug 1554409.

Comment 11

[forkest]

(In reply to Karl Tomlinson (:karlt) from comment #10)

I've read that bug 852963, I'm seeing that you're the only person who sees there a problem and wants to revert the bug 852522 that fixed on Windows the very same problem described in the current bug (the reasoning for implementing 852522 can be found in the bug 844604 comments 17-23).

I kind of understand you from the theoretical standpoint, but look at it from the practical side: what sense does it make to have a font in device pixels when the container around it is in CSS pixels? Sure, you say, then fix the layout, define the container size as relative to the font. Theoretically - great solution, practically - a lot of work and why bother when there's already the scaling system created for the web, created to fix the exact same problem with the web where text-based scaling broke layouts (see bug 852963, comment 7). Not to mention that scaling the theme in em/ex will likely make non-vector icons fuzzy even without scaling.

I hope you can get my point and reconsider your position.

P.S. In fact, the web is broken for scaling ever since everybody started to use px in layouts. Firefox's UI layout is just a part of this ugliness. Currently we bear with it and use proportional scaling where px becomes a virtual unit scaled according to the devPixelsPerPx variable. Just make the fonts on Linux also a part of this scaling, please.

Comment 12

[Karl Tomlinson (:karlt)]

It is not as simple as two wrongs making a right. Two wrongs leaves common use cases broken (comment #7).
e.g. bug 1439857 (and the associated repeat of this discussion in bug 1431337).

Comment 13

[forkest]

This is very strange, but after some time fiddling with the GDK SCALE environment variables and devPixelsPerPx property I have a profile that does honor devPixelsPerPx for the font sizes and behaves exactly as desired in that case: with -1 GDK_DPI_SCALE is honored, with custom value - as if GDK_DPI_SCALE was equal to this value. This relates to the font size of the tab bar, address bar, hamburger menu, system menu, and about window. The font in the preferences and about:confg still honors only GDK_DPI_SCALE and ignores devPixelsPerPx.

How do I debug this to find the reason of this behavior change? This is definitely a bug. I did not change any other property, AFAIR. A newly created profile does not show this behavior, a copy of the old one does.