1269274 - [GTK+ 3.18] UI text sizes no longer inherited from Linux system

Status: RESOLVED WONTFIX

(Core :: Widget: Gtk, defect)

Description

[Felix Miata]

Attachment: 132 DPI screenshot of SM 2.42 & 2.43 on Fedora 24/KDE5 on host big31

Tested failing:
SeaMonkey 2.43 on Fedora 24/KDE5 @132DPI on 64 bit host big31
SeaMonkey 2.43 on Debian Stretch/TDE @120DPI on 64 bit host big41
SeaMonkey 2.43 on openSUSE Tumbleweed/KDE3 @120DPI on 32 bit host gx280
Firefox 46 on Debian Stretch/TDE @143DPI on 64 bit host big41
All the above have in common use of Xorg servers > 1.17.x

Same FF 46 and SM 2.43 work as expected with Xorg servers <1.18.x e.g.:
Firefox 46 on openSUSE 42.1/KDE3 @120DPI on 64 bit host msi85
SeaMonkey 2.43 on Debian Jessie/TDE @108 DPI on 32 bit host gx280
SeaMonkey 2.43 on openSUSE 42.1/KDE3 @143DPI on 64 bit host big31
SeaMonkey 2.43 on openSUSE 42.1/KDE3 @120DPI on 64 bit host msi85

Firefox 45 and SeaMonkey 2.42 are both as expected on all the above hosts.

20160411140819 & 20160421124000 (GTK3) FF builds tested came from mozilla.org.
20160308130025 & 20160428113946 (GTK2) SM builds tested came from akalla.
SM was mostly tested with both modern theme, but default also failed.

To reproduce:
1.upgrade from rv45.0 to rv46.0
2.open the "upgraded" app

Actual behavior:
1.UI text smaller than rv45.0 & native apps, including Firefox tab titles
2.SeaMonkey tab titles remain as they were in rv45.0
3.page content is as expected

Expected behavior:
1.All UI text remains sized as it was in rv45.0, matching native apps
2.page content remains unaffected

Comment 1

[Karl Tomlinson (:karlt)]

Do you have some native GTK3 apps to compare sizes?

How is the size in the file selection dialog?

Comment 2

[Felix Miata]

Attachment: 132 DPI screenshot of rv46 FF filepicker on Debian Stretch/TDE on host big41

(In reply to Karl Tomlinson (ni?:karlt) from comment #1)
> Do you have some native GTK3 apps to compare sizes?

None that I'm aware of.

> How is the size in the file selection dialog?

Font sizes in picker equate to other rv46 UI sizes, vastly undersize.

Picker window size on initial open was disappointingly small, but the manually adjusted size is remembered on reopen even after browser restart.

Also noted in picker:
1.scrollbar completely disappears when either pointer leaves the picker window, or when pointer stops moving anywhere except over the phantom scrollbar location.
2.unhovered scrollbar width is barely wide enough to notice that it exists.
3.hovered scrollbar width is significantly wider than unhovered width, but significantly narrower than native scrollbar width.

Comment 3

[Karl Tomlinson (:karlt)]

Firefox is aiming to integrate with the GTK3 theme and settings.  If firefox
UI has the same size fonts as the file picker then it is probably achieving
that.

I suspect the cause of the difference here is GTK 3.18 no longer falling back
to screen dimensions when the is no explicit dpi setting.

https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f
https://git.gnome.org/browse/gtk+/log/gdk/x11/gdkxftdefaults.c?h=gtk-3-18

I don't want to make Gecko apps look different from other GTK3 apps, so I
don't think there is anything that can be done in Gecko here.

GTK has a gtk-xft-dpi setting and checks the Xft.dpi resource.

Comment 4

[Felix Miata]

rv47 does "look different" than Gimp 2.18, which I cannot tell whether is built on gtk3 or not, but is using correct UI fonts.

Xft.dpi is always explicitly set null here in order that all GUI apps are exposed exclusively to the logical display density configured either via xrandr startup script, or /etc/X11/xorg.con*, or absent either, to Xorg's own fallback (96). Xft.dpi is an interloper.

Comment 5

[Felix Miata]

Upstream bug:
https://bugzilla.gnome.org/show_bug.cgi?id=757142
"Recent change breaks HiDPI setup based on calculated or forced DPI"

was WONTFIX'd last October. Absent a reversal of that resolution, and subsequent fix, that seems to mean a fix needs to come from here, possibly a wrapper that discovers Xorg's DPI and makes it equal to otherwise unnecessary, and possibly unwanted, Xft.dpi, before launching any Mozilla app.

Comment 6

[Felix Miata]

Xorg enhancement request to work around this:
https://bugs.freedesktop.org/show_bug.cgi?id=98909

Comment 7

[Felix Miata]

Attachment: 143 DPI screenshot of rv17 FF, rv43 SM, rv50 SM and rv53 FF on openSUSE Tumbleweed/KDE3 on host gx780