GNOME Bugzilla – Bug 680659
Does not apply the scaling factor consistently
Last modified: 2015-06-24 21:41:27 UTC
To reproduce: Run gnome-tweak-tool, set the text scaling factor to 1.4 (required on laptops with Retina-like display to get a usable font size). Open Epiphany, go to google, search for lions. Actual result: some fonts (e.g. those in main search results with font size specified in pt) are correctly scaled, some (in the sidebar, with font sizes specified in px) are not, and the images are not scaled at all. Expected result: a web page with usable font sizes and consistent layout. E.g., you can scale everything (including images and fonts whose size is specified in px) by the text scaling factor. This is what Chromium does, except that it ignores the system-wide scaling factor completely and uses its own configurable scaling factor.
In fact, you already can get the "expected" rendering in Epiphany if you set the text scaling factor to 1.0 using gnome-tweak-tool, search for lions and press Ctrl++ twice. But other applications on this laptop need the scaling factor of 1.4, so this is not a solution.
Created attachment 250986 [details] [review] Patch that fixes the bug I am at GUADEC again, and I have a crude patch against this bug. The idea is to undo the DPI accounting via font size normalization and redo it using zoom levels. E.g., with 144 DPI, when Epiphany thinks it should have the 1.0 zoom factor, webkit's zoom is actually set to 1.5. A similar adjustment is performed when Epiphany wants to read the current zoom factor. The patch works fine on my Sony laptop, but I think I have missed some (possibly unneeded) initialization. If I add debug output to track values passed to and returned from the virtual zoom functions, I see some requests that get the virtual zoom before setting it. Webkit returns 1.0, and this gets scaled down. No visible effects (?), though, as that zoom factor is immediately overridden.
Dear developers, why are you still ignoring a bug with a patch that almost fixes it? The only unfixed case is the "this tab caused Epiphany to crash" message, and I need your help to figure out where to set the default zoom to catch this case.
Because we're busy? Please don't rant in bugzilla.
Could anyone please look at the patch and help me find a place in Epiphany source where I should add the initialization of the default zoom for error pages? The issue is unfixed for 2.5 years, and Epiphany is now the only application in GNOME that is incompatible with the "text scaling factor" accessibility option.
Oops, 1.5 years.
Created attachment 281812 [details] [review] Patch that fixes the bug Updated the patch to epiphany-3.12.1, but the same "incomplete" objection applies.
The same issue applies to gnome-online-accounts when one neewd to enter their Google password. It would be really nice to have this fixed in one central location (Webkit) instead of duplicating this patch logic across all applications that embed Webkit.
Based on the discussion with Owen Taylor, we have concluded that, with recent cairo, both get_screen_dpi() and gtk_widget_get_scale_factor() need to be taken into account. I have not tested the effect.
*** Bug 703337 has been marked as a duplicate of this bug. ***
I agree that this is a problem, but I don't want to take this patch because it's just a workaround. This needs to be fixed in WebKit so that other applications benefit too.