[Linux] Fallback to Adwaita light Gtk theme when system uses dark theme
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
People
(Reporter: asdfghrbljzmkd, Assigned: stransky)
References
Details
Attachments
(3 files)
|
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
|
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
|
117 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
Go to web pages with input boxes with a dark GTK theme set
Actual results:
Input boxes look weird
Expected results:
Input boxes look normal
This is a known issue. The solution is to set widget.content.gtk-theme-override to Adwaita by default. This report is specifically about setting this pref by default. Adwaita will always be present on systems with GTK+, which is already required by Firefox, so this change should have no chance of breaking things. https://bugzilla.mozilla.org/show_bug.cgi?id=1411425 is the real fix, this is just a stop-gap measure.
Note that this was spun off from bug 70315 comment 52.
Perhaps a slightly less dramatic version would be to change any theme name ending in ":dark" into the equivalent ending in ":light"... although I'm not sure how safe that is.
|
Assignee | |
Comment 3•6 years ago
|
||
I'm going to support that if we enable it only when:
- dark theme is used by system wide
- light variant of the theme is not available
that needs some tests at browser start but generally looks doable to me. Karl, do you think it's such solution suitable?
|
|
Assignee | |
Comment 4•6 years ago
|
||
btw. it also expects that widget.content.gtk-theme-override is empty.
|
||
Comment 5•6 years ago
|
||
That sounds good to me if you can see or find a good way to do that.
When I wrote https://bugzilla.mozilla.org/show_bug.cgi?id=1461538#c9, I couldn't see an easy way to determine whether a light variant was available.
|
|
Assignee | |
Comment 6•6 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #5)
That sounds good to me if you can see or find a good way to do that.
When I wrote https://bugzilla.mozilla.org/show_bug.cgi?id=1461538#c9, I
couldn't see an easy way to determine whether a light variant was available.
We should avoid themes with white text on black background. That causes black control elements which stands up from the web page. And when the page defines custom color of input elements (usually light) it leads to white-on-white scenario.
I think we can calculate saturation/lightness values and define a range of accepted text/background colors. IMHO we generally want light background with dark text and the color itself is not so important.
|
|
Assignee | |
Comment 7•6 years ago
|
||
We may also need to test it with some popular Gtk themes like Adwaita dark, Arc, Yaru.
|
|
Assignee | |
Comment 8•6 years ago
|
||
We recently disable system dark themes for Firefox chrome and content by gtk-application-prefer-dark-theme settings.
That option is no longer prefered by gnome project and was removed from tweaks tools. Theme makers are encouraged to use
a different name for the dark theme variants, like Adwaita-dark, Yaru-dark and so on. This option also does not
work when the Gtk theme si missing the light variant completelly.
To address that this patch implements a heuristicts based on https://www.w3.org/TR/AERT/#color-contrast
to check if the recent system Gtk theme has good contrast/visibility with default HTML colors
(white background and black text).
If the system theme fails the test we try to check and set gtk-application-prefer-dark-theme to false. If that also
fails we use Gtk theme defined by widget.content.gtk-theme-override for content. If widget.content.gtk-theme-override
is empty Adwaita:light theme is used.
This Gtk theme automation can be disabled by widget.content.gtk-dark-theme-autodetection preference. When set to false
the old widget.content.allow-gtk-dark-theme, widget.chrome.allow-gtk-dark-theme and widget.content.gtk-theme-override
work as before this patch.
This patch was tested with some distro default light themes (Ambiance, Radiance, Yaru - Ubuntu, Arc - KDE, Menta - MATE)
and dark/light themes are recognized correctly.
|
|
Assignee | |
Comment 9•6 years ago
|
||
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 11•6 years ago
|
||
A follow up bug may be to detect the theme and try a light variant of it. Gnome-tweks does pain directory scan to get all installed themes:
valid = ['Adwaita', 'HighContrast', 'HighContrastInverse']
valid += walk_directories(get_resource_dirs("themes"), lambda d:
os.path.exists(os.path.join(d, "gtk-3.0", "gtk.css")) or
os.path.exists(os.path.join(d, "gtk-3.{}".format(gtk_ver))))
and if a theme with "-dark" suffix is active we can try to set a theme without it, like Yaru-dark -> Yaru, Adwaita-dark -> Adwaita and so on.
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 12•6 years ago
|
||
Use standard Gtk/Gnome way to set Firefox Gtk theme. Gtk theme of web content can be still configured
by widget.content.allow-gtk-dark-theme and widget.content.gtk-theme-override.
Depends on D29823
|
||
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 13•5 years ago
|
||
Pushed by dluca@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/03970b83ea43
[Linux/GTK] Fallback to Adwaita light GTK theme for content when system theme has no light variant, r=karlt
https://hg.mozilla.org/integration/autoland/rev/167a564b3fda
[Linux/Gtk] Remove MOZ_ALLOW_GTK_DARK_THEME and widget.chrome.allow-gtk-dark-theme configuration keys, r=karlt
|
||
Comment 14•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/03970b83ea43
https://hg.mozilla.org/mozilla-central/rev/167a564b3fda
|
||
Updated•5 years ago
|
It seems like this caused the behavior of eIntID_SystemUsesDarkTheme to always return false, so that now users with dark themes now have different behavior for the prefers-color-schemed media query. I suspect that's not desirable, although I'm not sure.
I filed bug 1555565 on the regression mentioned in comment 15 (which affects Bugzilla, BTW, since bugzilla styling depends on the prefers-color-scheme media query).
|
||
Comment 17•5 years ago
|
||
Hello.
This is quite an unfortunate timing, because just yesterday after I was done editing my own Arc-Dark theme and cheering on the full system integration and real-time changes from GTK theming support, I updated Nightly to the latest version today and it broke half of the user interface theming.
I don't understand the reasoning behind the sudden change when everything was working properly for years. I think this bug report reminded me of an issue back in 2016 or 2017 where input boxes had black text on a dark background (if I remember correctly), but this had been fixed for years already.
Thankfully I have a backup of the previous version of Nightly so I double checked the input boxes in particular and there isn't anything wrong with them. I can provide screenshots and test other kinds of controls if you wish.
The latest version broke system colours displayed in pages, from about:blank's background colour, to all controls like scrollbars and buttons, all my custom userstyles that unset background and color properties, and even the selection colour. This effectively negates my dark theme and transforms it into whatever light theme it decided to use.
I tried adding about:config overrides mentioned in the reports but none of them did a thing. Though in my case this seems to be a regression and would hope the default browser configuration would use the system theme's controls, and the system colour toggle to work as usual.
I apologise if I haven't posted in the right thread, as there are quite a few related reports that are linked to this issue.
(I'm running Debian 9 with GNOME 3.22.)
|
|
Assignee | |
Comment 18•5 years ago
|
||
Hi Nabile,
is your dark theme used when you set widget.content.allow-gtk-dark-theme to true in about:config? If not please file a new bug for it and I'll fix that.
Thanks.
|
|
||
Comment 19•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #18)
Hi Nabile,
is your dark theme used when you set widget.content.allow-gtk-dark-theme to true in about:config? If not please file a new bug for it and I'll fix that.
Thanks.
Hello Martin,
Indeed that did fix everything, thank you ! Though it required a restart which I didn't do before posting here. I'm really sorry about that ! I expected the configuration edits to apply dynamically, but I should have been more thorough.
As I didn't experience illegible UI controls using dark themes over the years, do you know why this setting defaults to false instead of true ?
Could it perhaps be a regression from specific GTK versions shipped by other distributions, and as such are outside of Firefox's control ?
(By the way, this made me aware of the new CSS media rule for light/dark theming which bugzilla takes advantage of, that's fancy !)
|
|
Assignee | |
Comment 20•5 years ago
|
||
(In reply to Nabile from comment #19)
(In reply to Martin Stránský [:stransky] from comment #18)
Hi Nabile,
is your dark theme used when you set widget.content.allow-gtk-dark-theme to true in about:config? If not please file a new bug for it and I'll fix that.
Thanks.Hello Martin,
Indeed that did fix everything, thank you ! Though it required a restart
which I didn't do before posting here. I'm really sorry about that !
I expected the configuration edits to apply dynamically, but I should have
been more thorough.
Yes, unfortunately you need to restart the browser as it involves complete web page reload in this case so the internal theme invalidation is not enough. I'm glad it works for you.
As I didn't experience illegible UI controls using dark themes over the
years, do you know why this setting defaults to false instead of true ?
Could it perhaps be a regression from specific GTK versions shipped by other
distributions, and as such are outside of Firefox's control ?
I expect you don't visit broken web sites which set control background color only. It leads to white-on-white color on such pages when dark theme is used.
|
|
||
Comment 21•5 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #20)
I expect you don't visit broken web sites which set control background color only. It leads to white-on-white color on such pages when dark theme is used.
I feel the blame is 100% on the web developers assuming everyone uses black on white schemes, and not the web browser doing the right thing.
It should be taught that whenever you set a background colour you have to set the corresponding foreground colour as well, and vice versa. These properties go hand in hand and I wish it was common sense, and if not website users should notify webmasters to fix their styling. This sort of mistake can also very much happen from dark website authors which are used to their system colours being dark, not accounting for light theme users, however small that number may be.
It feels like the minority of careless website authors shouldn't override the great system integration Firefox has in place, and I think most users of dark themes also have handy userstyles or colour inversion addons which casually work around the edge cases. As it was when I landed on version 69, I was under the impression something broke in my system.
Plus, if the new media rule promoting support of light and dark themes takes off, it should embolden proper CSS design that benefits everyone.
|
||
Comment 22•5 years ago
|
||
Nabile,
you'd be very very wrong here. changing the behaviour and the assumptions of web developers every where is never going to happen, particularly when the browser most used for development (chrome) handles the issue by making the webpage content default to black on white.
trying to assign blame and make everyone else change already built, and released pages across the entire internet is never going to happen. the correct fix for this issue by firefox is to get inline with every other browser and default to black on white for webpages. its not the technically correct answer, its the pragmatic answer.
|
|
||
Comment 23•5 years ago
|
||
this issue is still not resolved, it does not fix the issue as describe in https://bugzilla.mozilla.org/show_bug.cgi?id=1466131 (which was marked as a duplicate)
|
|
||
Comment 24•5 years ago
|
||
forgot to mention I'm using the latest firefox 67.0 which is hte version this claims to resovle the issue in.
|
|
Assignee | |
Comment 25•5 years ago
|
||
(In reply to jljatone from comment #24)
forgot to mention I'm using the latest firefox 67.0 which is hte version
this claims to resovle the issue in.
It's fixed in Firefox 69, recent Nightly. It's in field "Target Milestone" which is a bit cryptic :)
|
|
||
Comment 26•5 years ago
|
||
Guess I'll continue to wait. ;) thnaks for the clarification.
|
|
||
Comment 27•5 years ago
|
||
(In reply to jljatone from comment #22)
Nabile,
you'd be very very wrong here. changing the behaviour and the assumptions of web developers every where is never going to happen, particularly when the browser most used for development (chrome) handles the issue by making the webpage content default to black on white.
trying to assign blame and make everyone else change already built, and released pages across the entire internet is never going to happen. the correct fix for this issue by firefox is to get inline with every other browser and default to black on white for webpages. its not the technically correct answer, its the pragmatic answer.
While I do not have exact statistics on how many illegible styles there are out there, and don't have user feedback on whether good system integration is even widely considered a strength, I'm of the opinion that incorrect behaviour shouldn't be encouraged for the sake of future generations of developers. For instance, in C you wouldn't go far at all if you didn't check if your variables are initialised. It's entirely understandable to miss some variable initialisation, and the right thing to do is to fix the error when notified. It's trivial to fix too, especially if it's supposed to be your profession.
The new features introduced by CSS are meant to gradually improve the situation by adding awareness to accessibility features across all kinds of configurations. If the dark theme user community submits bug reports to website authors, global support can only get better. :)
Though indeed I've been told it might be preferable if Firefox just used its own UI controls to streamline the interface and shortcomings of some native toolkits (i.e. background-color changes the shape of input boxes to a fallback version on GTK), as well as reducing maintenance efforts, just like Chrome, but yeah.
Still, I really appreciate your efforts to keep supporting native themes and thanks again for the help !
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 28•5 years ago
|
||
Ryan, I see you wontfixed it for 68 but I think it will be good to have it in FF68 / ESR along with Bug 1555565. Do you have any strong objection here?
|
||
Comment 29•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 31•5 years ago
|
||
Comment on attachment 9062469 [details]
Bug 1527048 - [Linux/GTK] Fallback to Adwaita light GTK theme for content when system theme has no light variant, r=karlt
Beta/Release Uplift Approval Request
- User impact if declined: When Gtk dark theme is used system wide, web page content (forms, buttons, entry fields) also uses dark colors which breaks web content and makes some page unusable.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: 1) Make system use dark theme (Adwaita-dark, Yaru-dark, Arc-dark)
- Browse to a page which uses forms (https://www.jakpsatweb.cz/html/formulare.html for instance) and check that the forms have light background and black text.
- List of other uplifts needed: Bug 1555565
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Linux/Gtk theme fix.
- String changes made/needed: none
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 32•5 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: Fixes long standing linux bug when web content is broken with system dark theme. There are some workarounds available which are no longer needed as the system theme is automatically detected and fallback theme is used for web content then.
[Affects Firefox for Android]: no
[Suggested wording]:
[Links (documentation, blog post, etc)]:
|
|
Assignee | |
Comment 33•5 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]:
[Affects Firefox for Android]:
[Suggested wording]:
[Links (documentation, blog post, etc)]:
|
||
Updated•5 years ago
|
|
||
Comment 34•5 years ago
|
||
Hi, After installing Gnome-tweaks and selecting the Adwaita-dark theme for the system, I was able to reproduce this issue in Firefox 67 but its Verified as Fixed in Nightly 69.0a1 (2019-06-18). I will mark this issue accordingly.
|
|
||
Comment 35•5 years ago
|
||
Comment on attachment 9062469 [details]
Bug 1527048 - [Linux/GTK] Fallback to Adwaita light GTK theme for content when system theme has no light variant, r=karlt
approved for 68.0b12
|
|
||
Updated•5 years ago
|
|
||
Comment 36•5 years ago
|
||
| bugherder uplift | ||
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 40•5 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #39)
Added to the Fx69 Beta release notes.
This was backported to 68 so it should be in Firefox 68 release notes.
|
|
||
Comment 41•5 years ago
|
||
So it was. 302 Julien in that case as I don't see any references to this change in the existing Fx68 relnote drafts.
|
|
Assignee | |
Comment 42•5 years ago
|
||
Thanks. Happy to provide any background info.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 43•5 years ago
|
||
Trying to make up some text here... "Improved support for dark system themes on Linux by more reliably falling back to a light theme for web content". Does that sound OK, or do you have a better suggestion?
|
|
Assignee | |
Comment 44•5 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #43)
Trying to make up some text here... "Improved support for dark system themes
on Linux by more reliably falling back to a light theme for web content".
Does that sound OK, or do you have a better suggestion?
I'd use more descriptive text, something like:
When dark system Gtk theme on Linux is used and widget.content.gtk-theme-override is not set then default Adwaita Gtk theme is automatically used for web content. This behavior can be disabled by widget.content.allow-gtk-dark-theme preference.
|
|
||
Comment 45•5 years ago
|
||
That feels way too technical. I'd rather not point people at about:config from the release notes.
|
|
Assignee | |
Comment 46•5 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #45)
That feels way too technical. I'd rather not point people at about:config
from the release notes.
okay.
|
|
||
Comment 47•5 years ago
|
||
Hi, This issue is verified as fixed in Beta 68, I'll mark it accordingly.
Description
•