Nixpkgs: firefox: Not respecting 'services.xserver.dpi' after moving to GTK3

[rbasso]

Issue description

Firefox is not being affected by the services.xserver.dpi settings anymore.

I don't understand it well enough to identify the cause, but I partially bisected the problem and it seems to be cause by enabling GTK3 as default:

--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -13714,7 +13714,7 @@ with pkgs;
   inherit (callPackages ../applications/networking/browsers/firefox {
     inherit (gnome2) libIDL;
     libpng = libpng_apng;
-    enableGTK3 = false;
+    enableGTK3 = true;
     python = python2;
     gnused = gnused_422;
   }) firefox-unwrapped firefox-esr-unwrapped;

• 2017-04-09 - commit dd25b6da62ca6bb6a28a87a39e3505cf6b6a933a - OK
• 2017-04-10 - commit 999cf98de9fadf368aa8eb160ecbc929e6e5499d - Possible origin
• 2017-04-10 - commit 0e0e7c1a8f89279a154881d78ed67f05b7b50817 - NOT OK

Steps to reproduce

• Close all open Firefox instances

• Run firefox in KDE having services.xserver.dpi set.

  nix-shell -p firefox --run firefox
  

• Check if Firefox correctly adjusted its resolution to match your DPI settings.

Technical details

• System: 17.09.git.f0fac3b (Hummingbird)
• Nix version: nix-env (Nix) 1.11.8
• Nixpkgs version: "17.09.git.f0fac3b578"

[rbasso]

Does anyone have any idea about why is that happening? @abbradar @edolstra

[abbradar]

Thanks for the ping. Hm, strange -- what happens if you use KDE's DPI settings?

[rbasso]

I searched a little deeper and was able to find some related bugs:

• Opensuse 1022830
• KDE 367499
• Mozilla 1269274
• GNOME 757142

So it seems to be is a GTK bug/regression/new feature, caused by this commit.

To my surprise, this new behavior was intentional and the bug is marked as WONTFIX! Here are the answers from the creator of the commit:

Users using a HiDPI setup will now have to edit multiple configuration files
to achieve the same result.

I don't consider this a serious problem. Once you are editing files in /etc/X11 manually, all bets are off anyway.

Yes. You need to have a properly configured system for software to work as intended. I think you're overstating the problem of going from
"I have to edit /etc/X11/xorg.conf"
to
"I have to edit /etc/X11/xorg.conf and /etc/X11/Xdefaults"

There was a discussion to workaround this in freedesktop.org, but it seems there it no hope to see that fixed in Xorg:

... There is absolutely no reason why it should be up to Xorg to bend over backwards to work around breakage _explicitly introduced_ by external developers. Xorg already provides a multitude of tools to expose DPI information (core API about display width and resolution, XRANDR information). If the toolkit refuses to use them, that's the toolkit issue, and users should complain with the toolkit developers (or work around the toolkit breakage in whatever way they can).

I believe this affects all the GTK3 packages in high resolution systems, which is unfortunate, considering that high resolution displays are increasingly common. That said, it seems there are some possible solutions:

1. Add the suggested patch to revert the GTK bug, without hope that it will be fixed upstream.
2. Workaround the bug, somehow setting Xft.dpi according to services.xserver.dpi (edit: or maybe fonts.fontconfig.dpi)
3. Revert the move of Firefox to GTK3, solving the problem only for Firefox.
4. Document somewhere the need to edit ~/.Xresources and add Xft.dpi there to match services.xserver.dpi.

I solved the problem locally adding the setitings in ~/.Xresources, which solves my immediate problem, but I think it is the ugliest workaround for the problem.

Edit: Related to #18559

[lheckemann]

Isn't Xft.dpi already set according to fonts.fontconfig.dpi? For me, setting fonts.fontconfig.dpi fixed most scaling issues in GTK applications.

[vcunat]

It would seem ideal if you didn't need any reconfiguration at all after connecting a different display. I've had checked on a few machines, and in all cases the size/DPI values were correctly auto-detected by X.

[rbasso]

Isn't Xft.dpi already set according to fonts.fontconfig.dpi?

It seems it is set there, @lheckemann , but the effect is different from setting it in .Xresources.

For me, setting fonts.fontconfig.dpi fixed most scaling issues in GTK applications.

For me, fonts.fontconfig.dpi doesn't solve it. Without setting it in .Xresources, both Firefox and Gnumeric do not scale as expected.

I've had checked on a few machines, and in all cases the size/DPI values were correctly auto-detected by X.

I don't think X has any problem to detect/report dpi. The problem seems restricted to applications using recent versions of gtk3.

I guess the problem is GTK3 applications ignoring dpi settings in favor of the value 96, unless it is set in .Xresources, @vcunat .

Can you confirm that both Firefox and Gnumeric scale correctly even without Xft.dpi set in .Xresources? Even after a logout/reboot?

[vcunat]

Yes, I had read that gtk3 commit you linked – it's a simple change.

[abbradar]

I won't be able to work on this (or NixOS at all) much until my exams finish (end of May) but just as a heads up: I wanted to solve this by adding a system-wide configuration file at /etc/X11/Xresources and populating it from services.xserver.dpi.

[abbradar]

Do I understand correctly that fonts.fontconfig.dpi fixes this correctly? I'm thinking of possible ways to fix this.

[rbasso]

Do I understand correctly that fonts.fontconfig.dpi fixes this correctly?

I don't think it so. Here, setting it has no effect in Firefox or Gnumeric. I imagined it was already set indirectly by services.xserver.dpi.

The only thing that fixes the problem for me, @abbradar, is adding a .Xresources to my home folder.

[abbradar]

@rbasso No, it wasn't set by services.xserver.dpi. I think GTK overrides fontconfig settings. Anyway see #25892 -- this patch can already be useful to you but before merging it I want to discuss merging those two settings.

[lheckemann]

I'd like to use the gtk+ patch, as it's the most sensible behaviour and should make GTK applications work just like everything else does without extra config, but it's incredibly impractical to do only for myself due to the huge amount of building (including webkit…) my laptop would have to do for this. So personally I'd prefer for the patch that gtk+ rejected to just get included with nixpkgs.

[rbasso]

@abbradar,

I just tested the patch from #25892, which correctly creates the /etc/X11/Xresources file with Xft.dpi set, but it is completely ignored by Firefox.

[lheckemann]

@abbradar Any intentions to PR your change?

[abbradar]

@lheckemann I did just this in #25892