Created attachment 466965 [details] Offline HTML page sample test case This may sound like bug #250987 / bug #250138, but it's not the exact same thing, because of one key difference: it manifests at normal (1.00) font scaling. It's more subtle / a potentially more rare occurrence though, so it was harder to spot compared to the other two bug reports. The test case is the front page of https://themes.tiki.org That website demonstrates that Epiphany 44.3 / WebKitGTK 2.40.3 renders fonts in an incompatible way that breaks layouts compared to Firefox 115 and Chromium 114, with default font scaling at 1.00x. Since that website might change in the future, I'm attaching not only screenshots, but also an offline HTML version saved using Firefox; Epiphany seems able to open it. As you can see in the attached screenshots, Epiphany renders all the fonts consistently fatter/bigger than other browsers. Firefox and Chromium render the font metrically identically among themselves, WebKitGTK is the outlier, and a ton of website layouts break in various ways when browsed with Epiphany. I was unable to find out why it renders differently in Epiphany vs the rest, given that my font settings are at the defaults. Enlarging the window width or shrinking the zoom level does nothing to improve results with the test case above.
Created attachment 466966 [details] Screenshot comparing Epiphany, Firefox and Chromium's rendering at identical window widths
Created attachment 466967 [details] Screenshot comparing Firefox's equivalent width required to match WebKitGTK's rendering This screenshot shows the kind of window width shrinking you need to do in Firefox to approximate the broken layout/text wrapping that EpiphanY/WebKitGTK exhibits at 1.00 font scaling.
Actually _still_ a duplicate of bug #250138 ; it turns out that the app tricked me I was tricked into believing the font scaling changes were _entirely_ applied live, but they weren't, only _seemed_ like they were, but the changes were partial. After restarting the browser, at font scaling 1.00, the page renders correctly. So it's still a font scaling issue. Sorry for the noise! *** This bug has been marked as a duplicate of bug 250138 ***