[Webkit-unassigned] [Bug 202194] REGRESSION(r244635): [GTK] White text on white background in 2.25/2.26 and dark GTK theme
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jan 27 16:04:36 PST 2020
Michael Catanzaro <mcatanzaro at gnome.org> changed:
What |Removed |Added
CC| |tpopela at redhat.com
Summary|[GTK] White text on white |REGRESSION(r244635): [GTK]
|background in 2.25/2.26 and |White text on white
|dark GTK theme |background in 2.25/2.26 and
| |dark GTK theme
--- Comment #3 from Michael Catanzaro <mcatanzaro at gnome.org> ---
OK, this regressed in r244635. The intent of that change was to fix bug #126907 and make text boxes readable in dark mode. Previously we used hardcoded black text on top of the theme background color, which was bogus because that is unreadable if the theme background color is dark. Well that's now fixed, but at the cost that we now have a disaster when the default (theme) text color is used on top of a custom background color.
So I'm not sure what we should do here. This a 2.24 -> 2.26 regression and it makes it difficult for distros to upgrade to 2.26, since both Evolution and Geary need to be separately patched to do this upgrade safely. Generally we treat changes that break applications as regressions, but it's unclear whether that's OK to do in this case. On the one hand, Evolution and Geary workarounds already exist and are very easy to deploy. Also, Evolution and Geary changes are absolutely required regardless of this issue, due to 2.26 dropping single web process mode. But on the other hand, any application breakage makes it extremely difficult to justify WebKit upgrades, and according to the security advisories, there are currently 23 CVEs currently fixed in 2.26 but not in 2.24. Also, we can (and do) patch WebKit to force individual apps to use single-process mode again by checking prgname, which allows updating WebKit to 2.26 while leaving Evolution and Geary unchanged at older versions.
So I don't know whether we should roll out r244635 or not.
Relevant consideration: dark mode on the web has *never* worked acceptably well, and it's very much lost cause for us. We've discussed this extensively in bug #197947, and I believe we have consensus that we need to remove dark mode support and force light mode until such time that we're able to develop an HTML theme that doesn't depend on GTK. (See that bug for details.) If we agree on that, then I think that tilts the balance in favor of rollout. Once we fix bug #197947, all other dark mode bugs will immediately go away, so the rollout won't really hurt anymore.
But perhaps another reasonable solution would be: if the text color is not specified, then use the theme text color only if the text is being displayed on the default background, otherwise use black if the background has been set (to anything other than the default theme background). Problem is, I don't know how to implement that, and I don't know whether that would be easy or really hard.
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-unassigned