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

RESOLVED WONTFIX

Status

()

defect
--
major
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: mrmazda, Unassigned)

Tracking

(Blocks 2 bugs, {access, regression, ux-discovery})

46 Branch
Unspecified
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

3 years ago
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
Do you have some native GTK3 apps to compare sizes?

How is the size in the file selection dialog?
Reporter

Comment 2

3 years ago
(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.
Reporter

Updated

3 years ago
Keywords: access, ux-discovery
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Reporter

Comment 4

3 years ago
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.
Summary: UI text sizes no longer inherited from Linux system → [GTK+ 3.18] UI text sizes no longer inherited from Linux system
Reporter

Comment 5

3 years ago
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.
Reporter

Comment 6

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

Updated

2 years ago
Reporter

Updated

2 years ago
Blocks: SM2.49-GTK3
You need to log in before you can comment on or make changes to this bug.