Bug 213148 – [WPE][GTK] WEBKIT_FORCE_SANDBOX (bwrap) results in pixelated font under Wayland where everything is nice with GDK_BACKEND=x11

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKitGTK

[Jan Pokorný [poki]]

Long story short:

https://bugzilla.redhat.com/1845743

      |
      v

"fix" (well, workaround) was, in the end, as simple as:

$ ln -s /etc/fonts/conf.d ~/.config/fontconfig

Distribution (here Fedora) appears to do a great job of
balancing the fonts regardless of what's installed at the
moment, something that would get pitifully dismissed at
the moment with sandboxing feature of WebKitGTK when run
on Wayland-enabled environment (why only here and not with
x11? cannot tell but perhaps some extension to X can act
as a "font configuration" proxy of sorts?).

At least that's what my observation tells.

In my very case, it made a crucial difference between
selecting nicely aliased Dejavu Sans font (without sandbox
and/or with x11) in *.ttf vs. Cantarell in *.otf thas was
apparently pixelated in closer examination (maybe the
truth is more complicated but on the whole, said workaround
restores exactly the desired behaviour, so I don't have
an urge to dig deeper).

The former is fully in-line with "fc-match sans" output.

Users usually have no extra need to change the preferred
fonts when the distribution mostly "just works" as per
above.

Thanks for reflecting the fontconfig preference more to
its entirety.

To be perfectly following everything, there are these
$FONTCONFIG_PATH, etc. variables, but that would be
rather overkill :-)

[Jan Pokorný [poki]]

Huh, nope, false start, I think I must have been tricked
with another, reliable workaround (export GDK_BACKEND=x11).

Closing till I make more progress in investigating this,
will reopen if there's anything WebKitGTK could do to
help.

Sorry for noise.

[Jan Pokorný [poki]]

For the record, running MiniBrowser alone does _not_
appear to be equivalent to isolating this case further,
starting with said Evolution usage:

> GApplication is required for xdg-desktop-portal access
> in the WebKit sandbox

Indeed, fonts are always rendered just fine with

  GDK_BACKEND=wayland WEBKIT_FORCE_SANDBOX=1

Following is much closer and _will_ actually manifest
the problem:

GDKWEBKIT_FORCE_SANDBOX=0 bwrap --bind /run/user/1000/bus /run/user/1000/bus  --bind .flatpak-info /.flatpak-info  --args 0 /usr/libexec/webkit2gtk-4.0/MiniBrowser

$ < bwrap-args \
    WEBKIT_FORCE_SANDBOX=0 GDK_BACKEND=wayland \
    bwrap --bind /run/user/$(id -u)/bus /run/user/$(id -u)/bus \
    --bind bwrap-flatpak-info /.flatpak-info \
    --args 0 \
    /usr/libexec/webkit2gtk-4.0/MiniBrowser

where:

- bwrap-args:

$ > bwrap-args { cat | tr '\n' '\0'; } <<EOF
--die-with-parent
--unshare-pid
--unshare-uts
--unshare-net
--ro-bind
/usr/bin
/usr/local/bin
--ro-bind
/etc
/etc
--dev
/dev
--proc
/proc
--tmpfs
/tmp
--unsetenv
TMPDIR
--dir
/run
--symlink
../run
/var/run
--symlink
../tmp
/var/tmp
--ro-bind
/sys/block
/sys/block
--ro-bind
/sys/bus
/sys/bus
--ro-bind
/sys/class
/sys/class
--ro-bind
/sys/dev
/sys/dev
--ro-bind
/sys/devices
/sys/devices
--ro-bind-try
/usr/share
/usr/share
--ro-bind-try
/usr/local/share
/usr/local/share
--ro-bind-try
/usr/share
/usr/share
--ro-bind-try
/lib
/lib
--ro-bind-try
/usr/lib
/usr/lib
--ro-bind-try
/usr/local/lib
/usr/local/lib
--ro-bind-try
/usr/lib64
/usr/lib64
--ro-bind-try
/lib64
/lib64
--ro-bind-try
/usr/lib64
/usr/lib64
--ro-bind-try
/usr/local/lib64
/usr/local/lib64
--ro-bind-try
/usr/libexec/webkit2gtk-4.0
/usr/libexec/webkit2gtk-4.0
--ro-bind
/usr/lib/systemd/resolv.conf
/usr/lib/systemd/resolv.conf
--ro-bind
/usr/share/zoneinfo/Europe/Prague
/usr/share/zoneinfo/Europe/Prague
--bind-try
/run/user/$(id -u)/$WAYLAND_DISPLAY
/run/user/$(id -u)/$WAYLAND_DISPLAY
--unshare-ipc
--bind-try
/home/$(id -un)/.cache/webkitgtk/applications
/home/$(id -un)/.cache/webkitgtk/applications
--bind-try
/home/$(id -un)/.local/share/webkitgtk/mediakeys
/home/$(id -un)/.local/share/webkitgtk/mediakeys
--bind-try
/home/$(id -un)/.local/share/webkitgtk/databases
/home/$(id -un)/.local/share/webkitgtk/databases
--bind-try
/run/user/$(id -u)/pulse
/run/user/$(id -u)/pulse
--ro-bind-try
/home/$(id -un)/.config/pulse
/home/$(id -un)/.config/pulse
--ro-bind-try
/home/$(id -un)/.pulse
/home/$(id -un)/.pulse
--ro-bind-try
/home/$(id -un)/.asoundrc
/home/$(id -un)/.asoundrc
--dev-bind-try
/dev/snd
/dev/snd
--ro-bind-try
/home/$(id -un)/.config/fontconfig
/home/$(id -un)/.config/fontconfig
--ro-bind-try
/home/$(id -un)/.fontconfig
/home/$(id -un)/.fontconfig
--bind-try
/home/$(id -un)/.cache/fontconfig
/home/$(id -un)/.cache/fontconfig
--ro-bind-try
/home/$(id -un)/.fonts.conf
/home/$(id -un)/.fonts.conf
--ro-bind-try
/home/$(id -un)/.config/.fonts.conf.d
/home/$(id -un)/.config/.fonts.conf.d
--ro-bind-try
/home/$(id -un)/.local/share/fonts
/home/$(id -un)/.local/share/fonts
--ro-bind-try
/home/$(id -un)/.fonts
/home/$(id -un)/.fonts
--ro-bind-try
/var/cache/fontconfig
/var/cache/fontconfig
--ro-bind-try
/home/$(id -un)/.local/share/gstreamer-1.0
/home/$(id -un)/.local/share/gstreamer-1.0
--bind-try
/home/$(id -un)/.cache/gstreamer-1.0
/home/$(id -un)/.cache/gstreamer-1.0
--ro-bind-try
/usr/libexec/gstreamer-1.0/gst-plugin-scanner
/usr/libexec/gstreamer-1.0/gst-plugin-scanner
--ro-bind-try
/usr/libexec/gst-install-plugins-helper
/usr/libexec/gst-install-plugins-helper
--dev-bind-try
/dev/dri
/dev/dri
--dev-bind-try
/dev/mali
/dev/mali
--dev-bind-try
/dev/mali0
/dev/mali0
--dev-bind-try
/dev/umplock
/dev/umplock
--dev-bind-try
/dev/nvidiactl
/dev/nvidiactl
--dev-bind-try
/dev/nvidia0
/dev/nvidia0
--dev-bind-try
/dev/nvidia
/dev/nvidia
--dev-bind-try
/dev/kgsl-3d0
/dev/kgsl-3d0
--dev-bind-try
/dev/ion
/dev/ion
--dev-bind-try
/dev/v4l
/dev/v4l
--dev-bind-try
/dev/video0
/dev/video0
--dev-bind-try
/dev/video1
/dev/video1
--ro-bind-try
/home/$(id -un)/.config/gtk-3.0
/home/$(id -un)/.config/gtk-3.0
--ro-bind-try
/home/$(id -un)/.local/share/themes
/home/$(id -un)/.local/share/themes
--ro-bind-try
/home/$(id -un)/.themes
/home/$(id -un)/.themes
--ro-bind-try
/home/$(id -un)/.icons
/home/$(id -un)/.icons
EOF

*** apparently, some tweaks may be needed,
    e.g. for another video device

- bwrap-flatpak-info:

$ > bwrap-flatpak-info cat <<EOF
[Application]
name=org.test.MiniBrowser
EOF

May I keep this open till the mechanics of the problem
is nailed down?

[Jan Pokorný [poki]]

sorry for the problem with the command above, diff:

- $ > bwrap-args { cat | tr '\n' '\0'; } <<EOF
+ $ > bwrap-args tr '\n' '\0' <<EOF

[Jan Pokorný [poki]]

Also skip the stray "GDKWEBKIT_FORCE_SANDBOX=0 bwrap" command
(original that I gradually refined below that).

[Jan Pokorný [poki]]

Somewhat minified bwrap-args:

> bwrap-args tr '\n' '\0' <<EOF
--die-with-parent
--ro-bind
/etc
/etc
--dev
/dev
--proc
/proc
--tmpfs
/tmp
--unsetenv
TMPDIR
--dir
/run
--ro-bind-try
/var/lib
/var/lib
--symlink
../run
/var/run
--symlink
../tmp
/var/tmp
--ro-bind
/sys
/sys
--ro-bind-try
/usr
/usr
--ro-bind-try
/lib
/lib
--ro-bind-try
/lib64
/lib64
--bind-try
/run/user/$(id -u)
/run/user/$(id -u)
--unshare-ipc
--bind-try
/home/$(id -un)
/home/$(id -un)
--dev-bind-try
/dev/snd
/dev/snd
--ro-bind-try
/usr/libexec/gstreamer-1.0/gst-plugin-scanner
/usr/libexec/gstreamer-1.0/gst-plugin-scanner
--ro-bind-try
/usr/libexec/gst-install-plugins-helper
/usr/libexec/gst-install-plugins-helper
--dev-bind-try
/dev/dri
/dev/dri
--dev-bind-try
/dev/mali
/dev/mali
--dev-bind-try
/dev/mali0
/dev/mali0
--dev-bind-try
/dev/umplock
/dev/umplock
--dev-bind-try
/dev/nvidiactl
/dev/nvidiactl
--dev-bind-try
/dev/nvidia0
/dev/nvidia0
--dev-bind-try
/dev/nvidia
/dev/nvidia
--dev-bind-try
/dev/kgsl-3d0
/dev/kgsl-3d0
--dev-bind-try
/dev/ion
/dev/ion
EOF

In this form, it also supports setting GDK_BACKEND=x11 in the main
"< bwrap-args" beginning command from [comment 2], and it exposes
this paradox this whole seems to be about:

- GDK_BACKEND=x11 -> nice fonts
- GDK_BACKEND=wayland -> pixelated fonts

On the same host, same session, same everything.

I don't grok why this would happen.

Can you advise, please?

[Jan Pokorný [poki]]

Just added ~final iteration of the reproducing command also to original https://bugzilla.redhat.com/show_bug.cgi?id=1845743#c19:

MINIBROWSER=$(which MiniBrowser 2>/dev/null \
  || echo /usr/libexec/webkit2gtk*/MiniBrowser)

WEBKIT_FORCE_SANDBOX=0 GDK_BACKEND=wayland bwrap \
--bind-data 0 /.flatpak-info \
--die-with-parent \
--dir /run \
--dev /dev \
--tmpfs /tmp \
--unsetenv TMPDIR \
--symlink ../run /var/run \
--symlink ../tmp /var/tmp \
--proc /proc \
--ro-bind /sys /sys \
--ro-bind /etc /etc \
--ro-bind-try /var/cache /var/cache \
--ro-bind-try /var/lib /var/lib \
--ro-bind-try /usr /usr \
--ro-bind-try /lib /lib \
--ro-bind-try /lib64 /lib64 \
--bind-try "/run/user/$(id -u)" "/run/user/$(id -u)" \
--bind-try "/home/$(id -un)" "/home/$(id -un)" \
--dev-bind-try /dev/snd /dev/snd \
--dev-bind-try /dev/dri /dev/dri \
$MINIBROWSER <<-EOF
	[Application]
	name=org.test.MiniBrowser
EOF

[Michael Catanzaro]

Each time you leave a new comment, I just get more confused. ;)

Does this fix the problem or not:

$ ln -s /etc/fonts/conf.d ~/.config/fontconfig

?

[Michael Catanzaro]

Although antialiasing can be configured in fontconfig, there are two ways to configure it: it could be configured to override desktop (cairo/GTK) font settings, or it could be configured to be overridden by the desktop font settings. The later is much more common. So my guess is that the desktop font settings are broken inside your sandbox.

Try running this test program with your bwrap command... does it give a different result than when run on your host?


// gcc `pkg-config --cflags --libs gtk+-3.0` test-antialiasing.c

#include <gtk/gtk.h>

int
main (int argc, char **argv)
{
  GtkSettings *settings;
  gint antialias;

  gtk_init (&argc, &argv);

  settings = gtk_settings_get_default ();
  g_object_get (settings, "gtk-xft-antialias", &antialias, NULL);

  switch (antialias)
    {
    case -1:
      printf ("CAIRO_ANTIALIAS_DEFAULT\n");
      break;
    case 0:
      printf ("CAIRO_ANTIALIAS_NONE\n");
      break;
    case 1:
      printf ("CAIRO_ANTIALIAS_SUBPIXEL or CAIRO_ANTIALIAS_GRAY\n");
      break;
    default:
      g_assert_not_reached ();
    }

  return 0;
}

[Jan Pokorný [poki]]

re [comment 7]

Thanks for bearing with me, Michael :-)

> Does this fix the problem or not:

Sorry, that was really infamous late-night false start :-/
You see there are quite some moving parts in the picture,
so brain farts on my side were likely imminent in this
hassle to get one particular "detail" right.

> Try running this test program with your bwrap command...
> does it give a different result than when run on your host?

Thanks a lot, if that's what WebKitGTK uses for decisions
exclusively, we are down at the root cause:

Outside (sway/Wayland):

> CAIRO_ANTIALIAS_SUBPIXEL or CAIRO_ANTIALIAS_GRAY

inside bwrap[*]:

> CAIRO_ANTIALIAS_NONE

but repeated with GDK_BACKEND=x11:

> CAIRO_ANTIALIAS_SUBPIXEL or CAIRO_ANTIALIAS_GRAY


But hey, correct me if I am wrong, XFT (as in gtk-xft-antialias)
is an X extension only thing, hence it shall not be the main
deciding factor when running solely under Wayland?
Might it be the reason?  My worries would then be that there's
no such a generic counterpart in Wayland, perhaps only
compositor specific ones.  Anyway, I'll keep digging, this
moved me forward a lot, indeed!



[*] modification:
- $MINIBROWSER <<-EOF
+ --ro-bind ./test-antialiasing /bin/test-antialiasing \
+ /bin/test-antialiasing <<-EOF

[Jan Pokorný [poki]]

Ok, I see more of the context now, which makes me think that
it's unlikely this would be somehow unique to WebKitGTK + bubblewrap
(IIUIC, Flatpak uses that very same sandboxing backend):

https://github.com/flatpak/flatpak/issues/2861

The only difference is that with Flatpak, you actively ask for
isolation to happen (hence can be reasonably sure that any
problems inside do not necessarily map to your installation
outside), whereas with Evolution, you naturally expect all-native
(and therefore see something botched as a pressing question mark
generator possibly affecting whole system in some way, as was
in my case).  The other, perhaps important difference, is that
the process of sandboxing is fully at hands of WebKitGTK in this
case, would any interim workaround be agreeable if applicable.

Strangely, I've already independently tried to move to their
proper locations (with installing full-blown gsd):

/usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.xsettings.gschema.xml
/usr/share/glib-2.0/schemas/org.gnome.settings-daemon.enums.xml

(note the dependency, wasn't discussed with that Flatpak issue)

files extracted from "dnf download gnome-settings-daemon.x86_64",
followed with "glib-compile-schemas /usr/share/glib-2.0/schemas/".

I even have the key-value inserted like this:
$ gsettings get org.gnome.settings-daemon.plugins.xsettings antialiasing 
> 'grayscale

But that alone didn't appear to help.

[Jan Pokorný [poki]]

So I can close this again, since there are no upstram ramifications.
Only upstream ones, if any.

So my previous [comment 2] was close:

> Strangely, I've already independently tried to move to their
> proper locations (with installing full-blown gsd):
> 
> /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.xsettings.gschema.xml
> /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.enums.xml
> 
> (note the dependency, wasn't discussed with that Flatpak issue)
> 
> files extracted from "dnf download gnome-settings-daemon.x86_64",
> followed with "glib-compile-schemas /usr/share/glib-2.0/schemas/"

As usual, there was a missing piece of a puzzle, and that was:

> systemctl --user restart xdg-desktop-portal{gtk,}

Side note: this step is not enforceable/cannot be automated in
post-install scripts, unless one iterates through all the logind
user sessions explicitly (feels extremely nasty), correct?

It fixes the problem for me!

Closing here and will follow up at particular downstream, as there
are quite some enhancements to make at the packaging level.

One last thing regarding code in [comment 8]:

Michael, do you know whether there is something similar (perhaps
more extensive) that would accompany some of the respective packages
(pango, cairo, gkt3...).  If not, you see it was actually rather
handy for troubleshooting, and you perhaps keep tabs on various
projects where it might be added to be readily usable at distro
level eventually.  What do you think?  It doesn't look the same
as gsettings thing, correct?

[Jan Pokorný [poki]]

And btw. I think I proved that MiniBrowser actually does _not_ perform
the sandboxing by default per [comment 2].  Not sure whether it is
expected or not, perhaps some clarification at least in the form
of titlebar changed from "X" to "X [sandboxed]" or so, is appropriate.

[Michael Catanzaro]

(In reply to Jan Pokorný [poki] from comment #11)
> One last thing regarding code in [comment 8]:
> 
> Michael, do you know whether there is something similar (perhaps
> more extensive) that would accompany some of the respective packages
> (pango, cairo, gkt3...).  If not, you see it was actually rather
> handy for troubleshooting, and you perhaps keep tabs on various
> projects where it might be added to be readily usable at distro
> level eventually.  What do you think?  It doesn't look the same
> as gsettings thing, correct?

I don't know, but probably not. I just wrote that test after looking at Source/WebCore/platform/graphics/gtk/GdkCairoUtilities.cpp to see how WebKit computes whether or not to use antialiasing.

(In reply to Jan Pokorný [poki] from comment #12)
> And btw. I think I proved that MiniBrowser actually does _not_ perform
> the sandboxing by default per [comment 2].  Not sure whether it is
> expected or not, perhaps some clarification at least in the form
> of titlebar changed from "X" to "X [sandboxed]" or so, is appropriate.

Right, in MiniBrowser you have to manually enable the sandbox. Probably that no longer makes sense, but that's an issue for another bug, another day....

[Jan Pokorný [poki]]

> Right, in MiniBrowser you have to manually enable the sandbox.
> Probably that no longer makes sense, but that's an issue for another bug,
> another day....

It's there so this won't get forgotten forever: [bug 213174].
Given the fonts used to be alright here all the time, I suspect
the sandboxing was actually never activated, if I am not mistaken
(again), not even with enablement via variable (and that was the
reason I was force to devise reproducer using raw bwrap ... or
I don't have any other explanation).

[Hannes Müller]

*** Bug 222883 has been marked as a duplicate of this bug. ***