Bug 1845743

Thanks for a bug report. You are right it's about WebKitGTK, that's what renders the text there.

I see there's missing antialiasing or something like that. I do not see anything related in WebKitSettings, neither in WebKitWebContext.

Evolution can do something wrong, especially when MiniBrowser works (or dev-help, or Epiphany, which use the WebKitGTK as well).

Michael, do you have any idea about this, please?

(sorry about the typos, had a bug filling spree yesterday,
this was the last one, perhaps too late)

Also gtk3-demo tested to be alright regarding fonts using
either mode.

IIUIC, Evolution uses bubblewrap for the WebKitGTK sandboxing
if it could have any impact.  Or perhaps with X, it is automatic
that some rendering/workspace attributes are inherited compared
to Wayland?

(In reply to Jan Pokorný [poki] from comment #2)
> Evolution uses bubblewrap for the WebKitGTK sandboxing
> if it could have any impact.

Evolution does it in rawhide, yes. You can disable it (or enforce it for other applications using WebKitGTK) with:

   $ export WEBKIT_FORCE_SANDBOX=0

Though when I try `WEBKIT_FORCE_SANDBOX=1 evolution` with webkit2gtk3 2.28.1 and evolution 3.36.1, then it doesn't do anything wrong (under GNOME). The fonts have the antialiasing, as expected.

The webkit2gtk3 2.29.1 is a very different story, there had been done many changes as a preparation for gtk4 (I forgot of it earlier). Nonetheless, I tried the same under GNOME with Wayland and the preview looks fine, with antialiasing and everything. I have installed:

   gnome-shell-3.37.2-1.fc33.x86_64
   webkit2gtk3-2.29.1-1.fc33.x86_64
   evolution-3.37.2-1.fc33.x86_64

Thus maybe it's somewhere deeper, in your desktop environment, not advertising the font settings on places where WebKitGTK expects them (though I'd expect these things should come through gtk-settings or some such thing).

Let's wait for Michael's response, maybe he knows better than me.

(In reply to Milan Crha from comment #1)
> Evolution can do something wrong, especially when MiniBrowser works (or
> dev-help, or Epiphany, which use the WebKitGTK as well).

Not likely, I can't imagine how Evolution could screw up font rendering. It would have to try really hard.

My first thought was that this is likely a bug in WebKit's FreeType font backend, but since you cannot reproduce the issue yourself, that causes me to suspect that this is broken only under sway, not under GNOME? If so, the chances of it being debugged by upstream are minimal. It's hard to imagine what sway might be doing differently than GNOME....

(In reply to Michael Catanzaro from comment #4)
> Not likely, I can't imagine how Evolution could screw up font rendering. It
> would have to try really hard.

Aha, I didn't think of it before, but when you are talking about it... Evolution does try hard, which seems to be contra-productive here. It checks whether "org.gnome.settings-daemon.plugins.xsettings" scheme is installed, and if it is, then it reads from it and uses the value in this way:

	if (aliasing_settings != NULL)
		aa = g_settings_get_string (
			aliasing_settings, "antialiasing");

	if (g_strcmp0 (aa, "none") == 0)
		smoothing = "none";
	else if (g_strcmp0 (aa, "grayscale") == 0)
		smoothing = "antialiased";
	else if (g_strcmp0 (aa, "rgba") == 0)
		smoothing = "subpixel-antialiased";

	if (smoothing != NULL)
		g_string_append_printf (
			stylesheet,
			" -webkit-font-smoothing: %s;\n",
			smoothing);

I guess I should drop that code, because it seems to be obsolete.

Jan, what does:

   $ gsettings get org.gnome.settings-daemon.plugins.xsettings antialiasing

return in swaywm, please?

It returns 'grayscale' here.

(In reply to Milan Crha from comment #5)
> 	if (smoothing != NULL)
> 		g_string_append_printf (
> 			stylesheet,
> 			" -webkit-font-smoothing: %s;\n",
> 			smoothing);
> 
> I guess I should drop that code, because it seems to be obsolete.

Yes, WebKit will apply the right antialiasing setting for you by default.

Looks like exactly what I mentioned earlier:

> I want live with as little of unnecessary packages around as possible

is currently backfiring if WebKit is not given a chance to decide
on its own?

$ gsettings get org.gnome.settings-daemon.plugins.xsettings antialiasing
> No such schema “org.gnome.settings-daemon.plugins.xsettings”

Will try to rebuild locally with said code dropped so as to report
whether is has any effect in my env.

Thanks for the responses so far, appreciated.

Actually, there is nothing to be commented out, since the code
(provided it behaves the same under debugging) won't run into
those decisions at all in my case (and GDK_BACKEND=x11 won't
change anything about that, it seems).

I even tried the contrary, let the code add:

> -webkit-font-smoothing: antialiased

unconditionally, but that won't help.

So this perhaps leaves Evolution code proper out of equations.

The question would be then, what makes the difference for
WebKitGTK component between x11 and waylands graphical backends
in the absence of respective "gsettings"?

I have a hunch that various things are figured out from the
environment automatically even when gsettings are not available,
incl. the ability/preferences for font antialising, perhaps?
And this "side-channel" depends on x11/wayland difference,
hence the component gets differing picture.  Interestingly,
x11 backend behaves exactly as expected here.  And standard
GTK UI (main menu, dialogs, etc.) is behaving as expected
everywhere.  Any chance of unification even despite the lack
of explicit "gsettings"?

re [comment 3]:

> Evolution does it in rawhide, yes. You can disable it (or enforce
> it for other applications using WebKitGTK) with:
> 
>     $ export WEBKIT_FORCE_SANDBOX=0

This did the trick!

Yes, I am using Rawhide:

$ rpm -q evolution
> evolution-3.37.2-1.fc33.x86_64

So the last thing to possibly disentangle here is how to retain
security advantage of sandboxing vs. sane font rendering when
there is no assisted enforcement (like with "gsettings", which
may help or not, but apparently, all is optimal with x11 backend
already).

(In reply to Jan Pokorný [poki] from comment #9)
> So the last thing to possibly disentangle here is how to retain
> security advantage of sandboxing vs. sane font rendering when
> there is no assisted enforcement (like with "gsettings", which
> may help or not, but apparently, all is optimal with x11 backend
> already).

Who knows. Got to figure out what it's trying to read that's not mounted in the sandbox.

BTW we're beyond Red Hat Bugzilla territory now... please report on WebKit Bugzilla, WebKitGTK component.

Ok, thanks so far.  Thought it might ring some immediate bell, but I see
that's not the case.  Will try to collect more data points and follow up
where suggested, putting a reference also here when that's the case.

Just to be clear: if you run evolution with GDK_BACKEND=x11 or WEBKIT_FORCE_SANDBOX=0, under swaywm, the antialiasing works? Either one or the other is sufficient to avoid this bug?

OK I asked around and I think we have a suspect. Do you have xdg-desktop-portal and xdg-desktop-portal-gtk running on your system? Without those running, GTK won't be able to access antialiasing settings inside the sandbox.

So I retract my request for a WebKit bug. Assuming this guess is right, I think we should add a Requires: xdg-desktop-portal-gtk to webkit2gtk3 package. (Well, we should do that even if this guess is not right, because lots more will be broken without portals running.)

re [comment 13]:
> if you run evolution with GDK_BACKEND=x11 or WEBKIT_FORCE_SANDBOX=0,
> under swaywm, the antialiasing works?

Yes, either is sufficient to render fonts in WebKitGTK based components
(beside reading pane, also editor of a new message) of Evolution.

(Both of these can be seen as security compromises, either app
non-isolation or possibly, I guess, malicious content non-isolation
in bad cases.)


re [comment 14]:

> Do you have xdg-desktop-portal and xdg-desktop-portal-gtk running
> on your system?

Yes, these were brought to this installation with Flatpak, and I checked
these are started as systemd unit services with my sessions.

> Without those running, GTK won't be able to access antialiasing
> settings inside the sandbox.

Yes, both where running.

For completeness, tried also:
XDG_CURRENT_DESKTOP=gtk /usr/bin/evolution
XDG_CURRENT_DESKTOP=gnome /usr/bin/evolution

Neither of these helped.

XDG_CURRENT_DESKTOP is normally unset in my environment.

OK, this needs to go to WebKit Bugzilla for investigation then. Please report upstream against the WebKitGTK component, then post a link here.

Michael,

it's really the WebKitGTK's bug, in the end, in a way it seems
to neglect system-wide (sane) font configuration. and perhaps
then, in desperation, fontconfig picks first "sans" font it can:

https://bugs.webkit.org/show_bug.cgi?id=213148

(actually glad this select-without-control font, luckily, happened
to be the eye offending one in my case, otherwise the problem would
keep on waiting for someone with less fortunate setup)

> in a way it seems to neglect system-wide (sane) font
> configuration

This part ^ was wrong, sorry, but overall, I believe this is something
in WebKitGTK.

For the record, was able to isolate the problem out of Evolution.
by mimicking how WebKitGtk is run under it:

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 \
/usr/libexec/webkit2gtk-4.0/MiniBrowser <<-EOF
	[Application]
	name=org.test.MiniBrowser
EOF


Notes:
- WEBKIT_FORCE_SANDBOX=0 is rather superfluous due to how
  WebKitGTK guards against self-inflicted recursion, I think
- I put it there nonetheless, since the actual sandbox is
  just triggered with this explicit bwrap command
- the bwrap command is far far more liberal than what
  WebKitGTK arranges on its own, but yet the problem reproduces
- importantly: using GDK_BACKEND=x11 restores nice fonts
- for some reason, FC_DEBUG=1 shows a lot of differences like
  these:

>  Match Pattern has 25 elts (size 32)
>       family: "Dejavu Sans"(w) "DejaVu LGC Sans"(w) "DejaVu Sans"(w) "BPG 2017 DejaVu Sans"(w) "DejaVu Sans"(w) "Arev Sans"(w) "DejaVu Sans"(w) "Bepa"(w) "DejaVu Sans"(w) "Hunky Sans"(w) "DejaVu Sans"(w) "Olwen Sans"(w) "DejaVu Sans"(w) "SUSE Sans"(w) "DejaVu Sans"(w) "Verajja"(w) "DejaVu Sans"(w) "VerajjaPDA"(w) "DejaVu Sans"(w) "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "Prima Sans"(w) "DejaVu Sans"(w) "DejaVu Sans"(w) "Bitstream Vera Sans"(w) "DejaVu Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi Sans"(w) "Nimbus Sans L"(w) "Nimbus Sans"(w) "Nimbus Sans"(w) "Helvetica"(w) "Nimbus Sans"(w) "Lucida Sans Unicode"(w) "BPG Glaho International"(w) "Tahoma"(w) "URW Gothic"(w) "Nimbus Sans"(w) "Nimbus Sans Narrow"(w) "Droid Sans"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) "Yudit Unicode"(w) "Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 M"(w) "Waree"(w) "Loma"(w) "Garuda"(w) "Umpush"(w) "Saysettha Unicode"(w) "JG Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w) "Mukti Narrow"(w) "malayalam"(w) "Sampige"(w) "padmaa"(w) "Hapax Berbère"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) "Microsoft YaHei"(w) "Microsoft JhengHei"(w) "WenQuanYi Zen Hei"(w) "WenQuanYi Bitmap Song"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen Modata"(w) "VL Gothic"(w) "IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w) "AR PL SungtiL GB"(w) "AR PL Mingti2L Big5"(w) "ＭＳ ゴシック"(w) "ZYSong18030"(w) "TSCu_Paranar"(w) "NanumGothic"(w) "UnDotum"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) "KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit Marathi"(w) "Lohit Maithili"(w) "Lohit Kashmiri"(w) "Lohit Konkani"(w) "Lohit Nepali"(w) "Lohit Sindhi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Meera"(w) "Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) "LKLUG"(w) "FreeSans"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial Unicode"(w) "Code2000"(w) "Code2001"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w) "sans-serif"(s) "sans-serif"(w) "ITC Avant Garde Gothic"(w) "URW Gothic"(w) "sans-serif"(w) "sans-serif"(w) "Helvetica"(w) "Helvetica Narrow"(w) "Nimbus Sans Narrow"(w) "sans-serif"(w)
>       familylang: "en"(s) "en-us"(w)
>       stylelang: "en"(s) "en-us"(w)
>       fullnamelang: "en"(s) "en-us"(w)
>       slant: 0(i)(s)
>       weight: 80(i)(s)
>       width: 100(i)(s)
>       size: 10.56(f)(s)
>       pixelsize: 11(f)(s)
> -     antialias: False(s)
> +     antialias: True(s)
>       hintstyle: 1(i)(w)
> -     hinting: False(s)
> +     hinting: True(s)
>       verticallayout: False(s)
>       autohint: False(s)
>       globaladvance: True(s)
>       scalable: True(s)
>       rgba: 5(i)(s)
>       lang: "en"(w)
>       fontversion: 2147483647(i)(s)
>       embeddedbitmap: True(s)
>       decorative: False(s)
>       namelang: "en"(s)
>       prgname: "WebKitWebProcess"(s)
>       symbol: False(s)
>       variable: DontCare(s)

That is clearly a by-symptom, yet the root cause is unknown.

Question just in case:
- how to recompile-free debug WebKitGTK under sandbox?
  sadly, WEBKIT_DEBUG=all is fruitless ... because of the sandbox?
  I hope this is something this was thought of in the context
  of sandboxing.  If not, we can perhaps do something about it.

Let me reopen this in the light of progress I made
towards the resolution of my rendering issue (see
https://bugs.webkit.org/show_bug.cgi?id=213148).

What I'd kindly suggest:


0. easy first step:

webkit2gtk3-2.29.1-1.fc33.x86_64
# or bubblewrap which is already in Requires:?

- Requires: xdg-desktop-portal
  # it is, de facto, taken for granted with bubblewrap style
  # of isolation, correct?

- Recommends: xdg-desktop-portal-gtk
  # per https://github.com/flatpak/flatpak/issues/2861#issuecomment-487291928
  # it appears as if this is not needed with KDE?

- Suggests: gnome-settings-daemon (?)


1. more complex, yet needed to achieve desktop environment
   neutrality

  * split schemas of some not-so-tightly-coupled plugins (or all)
    of gnome-settings-daemon to separate subpackages, here in
    particular:

    - gnome-settings-schema-common:
      /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.enums.xml

    - gnome-settings-schema-xsettings:
      /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.xsettings.gschema.xml
      (Requires: gnome-settings-schema-common)

    - ...TBD...

  * make xdg-desktop-portal-gtk Requires: gnome-settings-schema-xsettings

  * is there an easy way to restart xdg-desktop-portal* when new
    schemas with a known effect on xdg-desktop-portal* land?


2. distant future???

  * systemic consolidation of the portals, for sway/wlroot-based desktop
    environments, there's currently xdg-desktop-portal-wlr, but currently,
    one is not a substitute for the other, IIUIC -- would a progress towards
    that be desirable?  if so, there should then be a new virtual Provides,
    e.g. Provides: xdg-desktop-portal-virtual, which would then be implemented
    with all these DE-specific portals, but the clients (bubblewrap) could
    the require just this virtual provides (looser coupling)


What do you think?

I'd like to see a works-out-of-the-box (regardless what DE you use)
experience.

>  * is there an easy way to restart xdg-desktop-portal* when new
>   schemas with a known effect on xdg-desktop-portal* land?

I haven't met a precedent for user services yet,  I guess it's tricky
(side note at https://bugs.webkit.org/show_bug.cgi?id=213148#c11).

> 0. easy first step:

Michael already expressed something along these lines in [comment 15]

(In reply to Jan Pokorný [poki] from comment #20) 
> 0. easy first step:
> 
> webkit2gtk3-2.29.1-1.fc33.x86_64
> # or bubblewrap which is already in Requires:?
> 
> - Requires: xdg-desktop-portal
>   # it is, de facto, taken for granted with bubblewrap style
>   # of isolation, correct?
> 
> - Recommends: xdg-desktop-portal-gtk
>   # per https://github.com/flatpak/flatpak/issues/2861#issuecomment-487291928
>   # it appears as if this is not needed with KDE?
> 
> - Suggests: gnome-settings-daemon (?)

Let's do:

Requires: xdg-desktop-portal-gtk

The other suggestions don't seem appropriate for downstream. Upstream is going to have to decide how this is supposed to work.

Was it up to naive me, I'd tried to get rid of unnecessary proxies/portals
for things like detecting output properties (since access to the device/s
is already granted), at least in the fallback style:

  1. ask something directly

  2. on failure, resort to the portal chatter

Toyed with an idea of Wayland-generic patch to WebKitGTK using libdrm, but
quickly realized window manager inputs (unfortunately not unified) are needed:

- may not be straightforward to map to which physical screen does the asking
  application run at (also, hinting/antialiasing should be dynamic per what's
  the current state app vs. particular screen at the moment)

- libdrm is not always successful in telling you the truth, so
  user override may be needed, nonetheless
  (cf. https://github.com/swaywm/wlroots/pull/1533, realized it is
  my case as well, except there is a sane default unlike with
  GTK3 when "xsettings" cannot be read) so we are back at
  "xsettings" style of doing things, except that "xsettings" doesn't
  really consider the differences amongst the available screens
 
I think if there was a call for unification regarding "fetching screen
per app properties", there would rather be something that would truly
reflect the particular screen the app is being displayed at, i.e. some
(DBus?) method that window manager specific portals could implement
using some app handle as an input.  Only then, if that wasn't available,
would the "xsettings" fallback be useful.  That would allow for skipping
gnome-settings-daemon completely where otherwise not relevant, especially
in Wayland-only world.

> The other suggestions don't seem appropriate for downstream.

Well, upstream is usually not interested in how products
of the distribution tarball are split into distro packages.

Suggested split of gnome-settings-daemon would help immediately
to heal the gap that's there for non-Gnome users.  I'd called
that "controlled workaround".

What problems do you see with that?

Can send a PR towards GSD.rpm to that effect unless there's
a good reason not to.

(In reply to Jan Pokorný [poki] from comment #25) 
> What problems do you see with that?
> 
> Can send a PR towards GSD.rpm to that effect unless there's
> a good reason not to.

It's not going to be accepted. Let's solve this properly in the upstream issue.

re [comment 26]:

I just sincerely hope this is driven by (understandably good!) intention
to put pressure on devising something that would be useful across the
board while solving some technical limitations that are inherently
present with the xsettings approach (like said inability to distinguish
which type of antialiasing is appropriate regarding the particular
display output at hand).

We shouldn't need too much pressure, just got to decide how the problem ought to be handled. Anyway I have added the xdg-desktop-portal-gtk dependency in rawhide, so closing this. Let's continue to discuss the problem with the fonts schemas in https://github.com/flatpak/flatpak/issues/2861.

Oh, I see now, thank you:
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/31

Michael, I think my last questions on the topic, hopefully rightly here.

Is it expected that xdg-portal-desktop-gtk (user service in systemd world),
is supposed to be started on demand with DBus activation?

I am asking since this is the last remaining bit that doesn't work out of
the box in my setup of Evolution (with WebKitGTK under the hood), Fedora
Rawhide with provisionally provided GSettings schemas as mentioned elsewhere.

I need to launch it (here, start the systemd user service) manually, as it
won't get autostarted, e.g. when Evolution is started.  I am fine with
arranging the dependency at systemd unit level, but was feeling a bit guilty
that I am just masking a problem of not working the intended way.
Once I start it manually, Evolution/WebKitGTK renders everything perfectly
even in pure Wayland, sandboxed mode.

Note that, at the same time, xdk-portal-desktop was running for one reason
or another without my intervention when examined after-the-fact (once
Evolution was started, not sure if it was running before or not).

Thanks

(In reply to Jan Pokorný [poki] from comment #30)
> Is it expected that xdg-portal-desktop-gtk (user service in systemd world),
> is supposed to be started on demand with DBus activation?

I don't know, but it would certainly be more robust if it did.