Bug 250138 – [GTK] Changing system font-scaling factor results in messy rendering of the page (Epiphany, WebKitGtk)

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

Created attachment 464357 [details]
Epiphany scaling factor 1.5 to make thing propminent (in most cases 1.25 applied)

Increasing system font scaling factor results in messy rendering of the page in Epiphany.

Steps to reproduce:
1. Increase font scaling factor through 1) Gnome preferences -> Accessibility -> Large Text or 2) gnome-tweaks -> Fonts -> Scaling Factor 3) dconf org/gnome/desktop/interface/scaling-factor, etc.
2. Open Epiphany browser and observe the rendered page and Dev Tools

Actual Results:
Messy and broken layout - some elements are large, some are still small (like links, buttons etc).

Expected Results:
Page and all related elements are scaled proportionally to the host font scaling factor.

Build Date & Hardware:
Epiphany 43.0 WebKitGTK 2.38.1 Fedora Linux 37 (Workstation Edition) x86_64 GNOME 43.2 Wayland

Additional Information:
Firefox behaves in same conditions enlarging font and layout

Created attachment 464358 [details]
Epiphany scaling factor 1.25

Created attachment 464359 [details]
Clean system Epiphany vs Firefox scaling factor applied

Created attachment 464360 [details]
Clean system Epiphany vs Firefox without scaling

[Michael Catanzaro]

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

[Jeff Fortin]

I find the screenshots above to not be as obvious as they could be, as DuckDuckGo has too simple of a design.

The test case I provided in bug #250987, this article: https://www.lapresse.ca/international/europe/2023-01-22/guerre-en-ukraine-jour-333/l-allemagne-prete-a-autoriser-la-pologne-a-livrer-des-chars-leopard-a-kyiv.php

...makes it easier to spot the consequences.

For instance, here are comparisons between Chromium, Firefox, and Epiphany / WebKitGTK, at various font scaling factors:

* attachment 464597 [details] at font scale 1.00: all OK
* attachment 464598 [details] at font scale 1.15: WebKitGTK breaks the layout
* attachment 464599 [details] at font scale 1.30: WebKitGTK breaks the layout

[Jeff Fortin]

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

[Jeff Fortin]

Created attachment 466978 [details]
Screenshot comparing renderings at 1.20 font scaling on the Tiki themes front page

Bug #258962 reveals another great testcase for this: https://themes.tiki.org (screenshot attached here)

In that case the layout gets completely broken when font scaling is 1.20 (or when the font scaling was changed from 1.10 to 1.00 but the web browser has not been fully restarted). Note that in my screenshot, the picture shown in the page is random so it varies across browsers side-by-side, but it doesn't influence the layout in practice, as it is in its own column that is always the same width.

Attachment 466965 [details] is an offline HTML snapshot of that page (in case it changes over time) as a convenient sample. It was saved by Firefox, but Epiphany can open it fine.

[Michael Catanzaro]

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

[Calvin Walton]

I made a mistake in reporting Bug 259309 - the text scaling factor *is* actually getting applied.

But one thing I noticed is that Firefox applies it in a different way from WebKitGTK.

It seems like WebKitGTK uses the setting only to adjust font sizes, which can make fonts larger (relative to other parts of the page) than the designer expected, and for example changes the ratio of how many 'px' are in an 'em'. This is probably why page layouts are breaking?

But Firefox handles this very differently. Instead of adjusting only the font sizes, it adjusts the entire page scaling. So, for example, if you're running on a display with 200% scaling, and enable Large Text in GNOME (1.25×), then the result will be that `window.devicePixelRatio` reports 2.5. The font sizes reported in the web inspector or visible to the web page are unchanged; the page is just drawn as if it was zoomed in by 1.25×, or as if it was being drawn on a higher pixel density screen than is actually in use.

[Ethan Reesor]

Created attachment 467102 [details]
Wails app, native

[Ethan Reesor]

Created attachment 467103 [details]
Wails app, firefox

[Ethan Reesor]

Created attachment 467104 [details]
Wails app, epiphany

[Ethan Reesor]

Created attachment 467105 [details]
Wails app, falkon

[Ethan Reesor]

I believe I am encountering this issue. I am working on an application that uses https://wails.io/. Wails runs the frontend of the application in a WebKit GTK widget. Based on my testing, I believe this issue is specific to WebKit GTK, not WebKit. I tested with the native application, Firefox, Falkon, and Epiphany. Given that Firefox *does not* reproduce the issue, it seems specific to WebKit. Given that the native application and Epiphany *do* reproduce the issue, and Falkon *does not*, it seems specific to WebKit GTK, given that the native application and Epiphany use WebKit GTK, and Epiphany uses QtWebEngine.

- Native - attachment 467102 [details]
- Firefox - attachment 467103 [details]
- Epiphany - attachment 467104 [details]
- Falkon - attachment 467105 [details]

[Glen Whitney]

Created attachment 471099 [details]
epiphany just after opening on 283 dpi display

[Glen Whitney]

I am commenting as the author of https://github.com/WebKit/WebKit/pull/26938 to address https://bugs.webkit.org/show_bug.cgi?id=247980 -- the WebKit maintainers asked me to, and I would like to, address the concerns in this issue as best as possible in the course of that change to WebKit.

First, I have looked at reproducing the original concerns with epiphany. (I have not yet looked at the Wails app, but can try to if the discussion about epiphany doesn't seem to reach a resolution that appears like it will also apply in the Wails situation.)

However, it seems to me that the current version of epiphany (if I run `epiphany --version` on my laptop, it prints `Web 46.0`) has migrated to gtk 4.0. And it is my understanding that the concept of a "font scaling factor" has been removed from gtk 4.0 altogether. Indeed, if I run gnome-tweaks and change the font scaling factor (the last setting on the "Fonts" tab, under the "Size" heading) to various values and restart epiphany each time I set a new value there, epiphany looks identical regardless of the value. So I would suspect that folks affected by this issue are now seeing a different behavior than was originally reported, with respect to the influence of the font-scaling factor, i.e., that it now has no influence. If anyone concerned with this issue is able to verify, that would be great.

Nevertheless, it is clear to me that Epiphany does nevertheless currently have a scaling issue. There is still a concept of the "font dpi" in GTK4, it is controlled by the Xft.dpi GTK setting. And there is of course still a device pixel size - XWindows and/or GTK know the physical size of the display and the number of pixels in each direction. My laptop has 283 dpi, and correspondingly I have my environment set up so that Xft.dpi is 283, and I have made sure that XWindows is seeing the same pixel density.

To be completely explicit, if I execute `python3 -c 'import gi; gi.require_version("Gtk", "4.0"); from gi.repository import Gtk; print(Gtk.Settings.get_default().props.gtk_xft_dpi)'` it prints 289792, and 289792/1024 = 283.0; if I execute xrandr, the second line is `eDP-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 344mm x 215mm` and 3840/(344/25.4) is 283.5; and if I execute `xdpyinfo | grep resolution` it prints `resolution: 284x283 dots per inch` (there is some rounding error).

In this setup, if I execute `epiphany`, it comes up by default on the webpage `https://webkitgtk.org/` and the layout seems very broken: the fonts are a reasonable size, but the entire page is jammed into a tiny section of the center of the window; I just added the screenshot prior to this comment.

Presuming this screenshot is similar to what others on this issue are now seeing, I believe the underlying difficulty is that WebKitGTK is currently not scaling the *non-font* dimensions of the layout properly. In other words, if in this same setup I visit a page like `https://katydecorah.com/css-ruler`, the size of the square with CSS side length `1in` is just over a quarter of an inch (very close to one-third of an inch, actually).

Therefore, what the PR referenced above does is arrange that the device pixel size (the common output of the xrandr/xdpyinfo resolution results) is used to scale the non-font dimensions of the layout. And then Xft.dpi is used to scale the fonts. In my setup, this has no effect on font size; as you can see in the screenshot, they were already reasonable, as epiphany/WebKitGTK was already using Xft.dpi to scale the fonts. But it roughly triples the size of the region used for the layout, so the page now renders very reasonably; I will post a screen shot right after this comment.

So once the PR lands, when a web page is viewed at the default magnification, a CSS 1in dimension should literally measure one physical inch on the screen, and as long as the Xft.dpi setting matches the device pixel density as well, a 96px=72pt font will also measure exactly 1in high on screen.

Note that one thing the proposed PR does _not_ do is create an effect of Xft.dpi on the non-font dimensions of a web page. The non-font-related dimensions will correspond exactly to the device pixel density as reported by GDK, which stem from the resolution as reported by xrandr/xdpyinfo, possibly adjusted by the overall integer scaling factor GDK_SCALE. That keeps 1in in CSS pegged to one actual inch on screen, which HTML5 and CSS standards would seem to require (and which WebKitGTK currently fails to do when the device pixel density is anything other than 96 dpi).

In other words, if in your setup Xft.dpi does not match the observed device pixel density, then layouts will not necessarily match their original design, with text being larger or smaller than the space allocated for it. But I would suggest (a) that's exactly the expected behavior under GTK -- for all other GTK applications, changing Xft.dpi away from the actual device dpi changes just the font sizes, not the layouts, often leading to broken-looking layouts (e.g., button labels not fitting in their buttons), and (b) as long as you create a setup in which Xft.dpi and the reported device pixel density match, the referenced PR will solve the issues reported here. I do not think it would be semantically consistent, or consistent with CSS standards, for changing Xft.dpi to bleed over into changing the non-font dimensions of web pages.

So looking forward to any feedback that anyone concerned with this issue may have, and if there are suggestions that would impact the PR that would receive the approval of the WebKitGTK maintainers, I would be happy to incorporate them.

[Glen Whitney]

Created attachment 471101 [details]
minibrowser in same setup with the proposed PR

(epiphany will look very similar; I just don't have a version linked with the patched WebKitGTK at the moment)

[Michael Catanzaro]

So if I understand correctly, there is nothing more to do here after fixing bug #247980, yes? It's OK to close this?

The Large Text accessibility setting behaves reasonably when using GTK 4 after your pull request?

[Glen Whitney]

(In reply to Michael Catanzaro from comment #18)
> So if I understand correctly, there is nothing more to do here after fixing
> bug #247980, yes? It's OK to close this?

That is indeed my feeling, but I have also come to realize that there is quite a diversity of GTK setups out there. So if I were a maintainer, I'd love to get feedback from one of the folks that was actually affected by the concerns as stated here, as they are phrased somewhat differently from the issue #247980 that I am directly addressing.
 
> The Large Text accessibility setting behaves reasonably when using GTK 4
> after your pull request?

Could you let me know how in a GTK4 environment I can for sure turn on that accessibility setting? (I don't use the Gnome desktop for example, but I can install and run any publicly available GTK4 app, so if there is some sort of GTK4 settings app that would include this accessibility setting please point me to it, thanks. Or maybe there is a `gsettings` command-line I could execute to do it?)

And what would you consider "behaves reasonably"?  E.g.,
  * makes type whatever percentage larger, but leaves the width of dimensioned divs like sidebars alone, so there will be fewer words per line in such dimensioned divs, making the text take up more vertical space and perhaps introducing some odd line breaks, etc.; or
  * makes type whatever percentage larger and also grows other dimensions, so that it basically acts like a screen magnifier within the context of a web page? (In other words, for web pages basically is equivalent to increasing the default zoom from one to some percentage larger than one.)
  * Or something else?

  I'd be happy to test it and see if its behavior matches your hopes/expectations.

[Ethan Reesor]

I had Epiphany installed via Flatpak. It's not a browser I use, I just installed it for testing purposes. I tried updating it and now it's totally broken (just a white screen). Not sure what happened there but I don't have the interest to debug it since I don't actually use it.

I'm not familiar with the underlying mechanics, so I can't speak on that. My use case is Wails, which currently has a hard dependency on gtk+-3.0 and webkit2gtk-4.0. There's an open ticket to upgrade to webkitgtk-6.0, but no movement on it.

What I consider to be "behaves reasonably" is more or less "Are there issues that significantly reduce the usability of my app?" In the example I used, there's a button containing the text "Greet". In Firefox and Falkon, the button and text are scaled the same amount so it looks right. That's the behavior I expect. In WebKit GTK (Epiphany, Wails), the text is scaled something like 2x more than the button so the rendering is totally screwy and the text is hard to read.

[Glen Whitney]

(In reply to Ethan Reesor from comment #20)
> My use case is Wails, which currently has a hard dependency on gtk+-3.0 and
> webkit2gtk-4.0. There's an open ticket to upgrade to webkitgtk-6.0, but no
> movement on it.
> 
> What I consider to be "behaves reasonably" is more or less "Are there issues
> that significantly reduce the usability of my app?" In the example I used,
> there's a button containing the text "Greet". In Firefox and Falkon, the
> button and text are scaled the same amount so it looks right. That's the
> behavior I expect. In WebKit GTK (Epiphany, Wails), the text is scaled
> something like 2x more than the button so the rendering is totally screwy
> and the text is hard to read.

OK, so I am presuming everything that you're trying to do is in a GTK 3 context. There, the text-scaling-factor is operative, and the referenced PR does attempt to respect it. Will it affect the issues you are seeing? Without your trying to run the applications you are interested in with the dynamic webkitgtk libraries they use replaced with ones compiled from the PR, the best I can say is "probably". Is trying to run it that way at all in the cards for you? (Don't know your level of concern with this issue and/or your ease/comfort with compiling WebKitGTK from source and swapping in the resulting libraries.)

I say "probably" because in GTK3, there are lots of settings, and as I have found, a lot of different ways that people have their XWindows and GTK environments set up. I can only summarize by saying: "If the device pixel density that your GTK setup ends up detecting is roughly equal to the product of your Xft.dpi setting and your text-scaling factor, then your layout will look pretty good after the PR." If you are not sure about all of those things, you can try to get a handle on them by (in the browser/environment of concern) visiting https://katydecorah.com/css-ruler, and setting the body font size to 96px. Then look at the first green box on the right labeled "1em" and the purple box labeled "1in". If they look about the same size, then your layout after this PR will probably be pretty good.

If you have any other suggestions about how WebKitGTK should respond to GTK 3 settings, I am all ears. The one thing I don't think we can do is increase `physical` CSS dimensions based on the text-scaling factor. That would be making that text-scaling factor scale things other than text, which would seem to be against GTK semantics, and would also be making CSS 1in dimensions be other than one physical inch on screen, which would seem to be against HTML/CSS standards. Thanks again!

[Michael Catanzaro]

(In reply to Glen Whitney from comment #19)
> Could you let me know how in a GTK4 environment I can for sure turn on that
> accessibility setting? (I don't use the Gnome desktop for example, but I can
> install and run any publicly available GTK4 app, so if there is some sort of
> GTK4 settings app that would include this accessibility setting please point
> me to it, thanks. Or maybe there is a `gsettings` command-line I could
> execute to do it?)

$ gsettings set org.gnome.desktop.interface text-scaling-factor 1.25

# When done
$ gsettings reset org.gnome.desktop.interface

This setting *does* affect GTK 4 apps, including WebKitGTK web views.

[Glen Whitney]

(In reply to Michael Catanzaro from comment #22)
> (In reply to Glen Whitney from comment #19)
> > Could you let me know how in a GTK4 environment I can for sure turn on that
> > accessibility setting? (I don't use the Gnome desktop for example, but I can
> > install and run any publicly available GTK4 app, so if there is some sort of
> > GTK4 settings app that would include this accessibility setting please point
> > me to it, thanks. Or maybe there is a `gsettings` command-line I could
> > execute to do it?)
> 
> $ gsettings set org.gnome.desktop.interface text-scaling-factor 1.25
> 
> # When done
> $ gsettings reset org.gnome.desktop.interface
> 
> This setting *does* affect GTK 4 apps, including WebKitGTK web views.

I am running epiphany Web 46.0 as packaged by openSUSE Tumbleweed, and ldd confirms that it is linked to /lib64/libwebkitgtk-6.0.so.4, which rpm verifies is from libwebkitgtk-6_0 as packaged by Tumbleweed, and gsettings is version 2.80.0 in package glib2-tools, and regardless of what number I put at the end of the command line

$ gsettings set org.gnome.desktop.interface text-scaling-factor XXXX

epiphany looks absolutely identical, from its address bar to its icons to its website content text to its layout. I take it that is not the case for you? How would you like me to proceed -- is there any concern that my setup is not appropriate for testing, casting doubt on https://github.com/WebKit/WebKit/pull/26938 ? I will say I _do_ see a significant difference in behavior, with layout much improved, when I compile and run with that code (which I have only done with the minibrowser, not epiphany, but I could try to link epiphany with the resulting libraries if you feel it would be helpful). Thank you very much for the guidance -- I definitely would like to contribute, and improve layout I am seeing from WebKitGTK, but I also don't want to harm anything if I am not seeing proper behavior of existing code on my end.

[Michael Catanzaro]

(In reply to Glen Whitney from comment #23)
> $ gsettings set org.gnome.desktop.interface text-scaling-factor XXXX
> 
> epiphany looks absolutely identical, from its address bar to its icons to
> its website content text to its layout. I take it that is not the case for
> you?

Right: my text gets 20% larger. Do you have gsettings-desktop-schemas installed?

I think it's OK to land your pull request now while we continue to discuss this bug, since it fixes bug #247980.

[Glen Whitney]

(In reply to Michael Catanzaro from comment #24)
> 
> Right: my text gets 20% larger. Do you have gsettings-desktop-schemas
> installed?

Yes. Is there a daemon that needs to be running? It doesn't seem as though,
because if I do

$ gsettings get org.gnome.desktop.interface text-scaling-factor

I get back whatever the last value was. But epiphany just stubbornly looks identical regardless.

> 
> I think it's OK to land your pull request now while we continue to discuss
> this bug, since it fixes bug #247980.

OK, if that's your preference. I am sorry about my inability to provide a fully satisfying test environment for it. I'll fix the code formatting items and mark it as ready again.

[Michael Catanzaro]

(In reply to Glen Whitney from comment #25) 
> Yes. Is there a daemon that needs to be running?

If you've installed Epiphany on your host system, then no. But if you've installed Epiphany via flatpak, then you would need xdg-desktop-portal and xdg-desktop-portal-gtk to expose desktop settings.

[Glen Whitney]

(In reply to Michael Catanzaro from comment #26)
> > Yes. Is there a daemon that needs to be running?
> 
> If you've installed Epiphany on your host system, then no. But if you've
> installed Epiphany via flatpak, then you would need xdg-desktop-portal and
> xdg-desktop-portal-gtk to expose desktop settings.

Hmm, my epiphany is from the standard OpenSUSE Tumbleweed packaging of epiphany, so it sounds like I shouldn't need to worry about any other daemons. I am at a loss to understand why the setting is having no effect. I very much hope that landing https://github.com/WebKit/WebKit/pull/26938 won't cause any regression in Epiphany's respect of this setting. Hopefully that's something that someone will be able to test before any release of WebKitGTK that would have these changes?

[Michael Catanzaro]

I will test your pull request. No clue why the setting doesn't work for you.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #28)
> No clue why the setting doesn't work for you.

OK, I think it's because the setting is only respected if running in a Wayland session (because the only place that reads it is gdkdisplay-wayland.c). But you're using an X session, right? So that's why. (You could hack WebCore::fontDPI in PlatformScreenGtk.cpp to emulate the setting easily enough, though, just for testing purposes. But don't feel obligated to continue investigating unless you want to.)

I confused myself for a while because I was changing the setting on my host system rather than the setting in my jhbuild environment (which has a separate settings database), and left an incorrect comment in https://github.com/WebKit/WebKit/pull/26938 complaining that it broke the setting. I commented too soon, before verifying that the setting still works properly after reverting your changes. Your changes have no impact on this bug: it's no better or worse than before.

[Glen Whitney]

(In reply to Michael Catanzaro from comment #29)
> But you're using an X session, right? So that's why.
> (You could hack WebCore::fontDPI in PlatformScreenGtk.cpp to emulate the
> setting easily enough, though, just for testing purposes. But don't feel
> obligated to continue investigating unless you want to.)

Yes, I am running under XWindows, not Wayland.

Sorry, I am left a bit confused; is there a remaining bug with GDK/GTK 4 (and/or 3) that I should have addressed in my PR? If so, what is it/how do I reproduce it, and what's the desired behavior? Is the problem precisely that current released Epiphany under XWindows/GTK 4 does not respect text-scaling-factor and it should?

If that's it, then that would bring us back full circle to the point concerning which this bug was filed: Suppose text-scaling-factor was set to 2 and that was interpreted to make all letters in webpage text content twice as large. If absolute CSS dimensions like '1in' or '96px' remain fixed as one physical inch, then layouts will tend to look broken. But rendering CSS 1in at default zoom as anything but one physical inch (or a certain angle of the field of view at the expected viewing distance) would seem to be a violation of HTML/CSS standards, and using text-scale-factor to change other non-text dimensions would seem to defy the plainly stated meaning of "text-scale-factor," i.e., that it scales text. 

So if you would like me to try to address some remaining problem here connected with what I have just done, I am happy to, just please do make it clear what would be considered "correct" behavior. Thanks!

[Michael Catanzaro]

(In reply to Glen Whitney from comment #30)
> Sorry, I am left a bit confused; is there a remaining bug with GDK/GTK 4
> (and/or 3) that I should have addressed in my PR? 

No.

> Is the problem precisely that
> current released Epiphany under XWindows/GTK 4 does not respect
> text-scaling-factor and it should?

No.
 
> So if you would like me to try to address some remaining problem here
> connected with what I have just done, I am happy to, just please do make it
> clear what would be considered "correct" behavior. Thanks!

Nope, I've sent your pull request to merge queue.

This bug report remains, and I guess the only solution would be to scale the entire UI based on the text scaling factor. That can be done in the future, though.

[Michael Catanzaro]

Should be fixed by https://github.com/WebKit/WebKit/pull/28691