Closed Bug 1269274 Opened 5 years ago Closed 4 years ago
.18] UI text sizes no longer inherited from Linux system
249.13 KB, image/png
291.40 KB, image/png
143 DPI screenshot of rv17 FF, rv43 SM, rv50 SM and rv53 FF on openSUSE Tumbleweed/KDE3 on host gx780
351.07 KB, image/png
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?
(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.
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: 4 years ago
Resolution: --- → WONTFIX
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
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.
Xorg enhancement request to work around this: https://bugs.freedesktop.org/show_bug.cgi?id=98909
You need to log in before you can comment on or make changes to this bug.