about:home has a light background color on linux systems, when it should have a dark background color, because my system uses a dark theme. about:preferences and about:config are displayed with a dark background as intended.
Setting ui.systemUsesDarkTheme to true doesn't change this behavior.
browser.in-content.dark-mode is set to true on my system.

I created a blank profile to verify that I don't experience this behavior because my profile is corrupt.

(In reply to jkhsjdhjs from comment #0)

Setting ui.systemUsesDarkTheme to true doesn't change this behavior.

true should be 1 since the setting is a Number value.

This depends on Bug 1529323 since the built-in light and dark themes still need to override the system colors for the new tab page like they do currently.

about:newtab and about:home are displayed in their dark themes only when extensions.activeThemeID is set to firefox-compact-dark@mozilla.org. Or if you have set the dark theme from about:addons->themes.

There's also bug 1529897 that's fixed, which makes is so Firefox themes are not overridden by the OS set theme.

@jkhsjdhjs could you please check and see that if you switch the browser over to Dark theme the about:newtab and about:home pages also switch to dark theme?

This bug is specifically for the Default theme where it is expected that the OS light/dark mode is applied consistently to all about:pages.

(In reply to Kestrel from comment #4)

@jkhsjdhjs could you please check and see that if you switch the browser over to Dark theme the about:newtab and about:home pages also switch to dark theme?

Yes, about:newtab and about:home are displayed with a dark background color when explicitly enabling the dark theme.

As verified in comment #5, on linux about:newtab displays dark on explicitly enable dark theme in Firefox.

NI Kestrel to help clarify work needed post Bug 1529323 fix to support system dark mode on linux with gtk themes for about:new tab pages. It will help assign bug to correct component.Thanks!

Here's the situation right now:

• about:newtab follows the current browser theme and can be styled by browser themes (Arc Dark theme is an example), mainly for Chrome parity
• The default theme automatically becomes the dark theme when the system dark mode is used, except on Linux, where the default theme already uses system colors. This has the side-effect of about:newtab staying light on Linux for dark GTK themes.
• The in-content dark mode follows the system theme rather than the browser theme, regardless of what browser theme is selected and which platform is used.

FWIW, the current situation matches Google Chrome's behaviour on MacOS and Windows. Not sure about Linux however.

Dão, do you think something should be done about this ? I do think the current situation is confusing, but I'm also not sure how much better we can do here.

I think we should probably fix bug 1529323 and let about:newtab use prefers-color-scheme.

Since add-on themes can already restyle these pages, wouldn't it make sense to simply export the required pieces of information for the built-in themes as well? This way no special-casing for firefox-compact-dark@mozilla.org would be needed and the pages would actually use system colors when using the Default theme on all platforms. Would this be a thing that realistically could be done?

Moving this bug to our backlog until Bug 1529323 is fixed.

Instead of relying solely on the theme to make about:newtab dark, use prefers-color-scheme as well like other about: pages. This makes it work on Linux for the Default theme combined with dark GTK themes and also avoids a white flash on load as the dark mode can be applied immediately rather than waiting for theme colors. The light theme must now explicitly apply newtab colors to override dark mode.

This is a very annoying bug, and something should really be done here, as it results in a very inconsistent UX. about:preferences works as expected, but about:newtab is blinding. Reading the thread, it seems there were concerns that having a dark newtab when the Light FF theme is enabled could also be a problem, and that the proposed patch would cause a dark flash when using Light FF with a dark system theme. Maybe a workable solution would be this:

Instead of if (getPref("extensions.activeThemeID") == "firefox-*-dark@mozilla.org") { dark_newtab=true; }, which is the current logic, have:

if (getPref("extensions.activeThemeID") == "firefox-*-dark@mozilla.org" || 
        (getPref("extensions.activeThemeID") == "firefox-default@mozilla.org" && getCSSProperty("prefers-color-scheme") == "dark"))
{
    dark_newtab=true;
}

This way, the Default theme behaves as expected, without potentially adding unwanted behavior/bugs for the Light FF theme.

Honestly, any solution that gets me a dark newtab theme when on Default would be super awesome, FF's Dark theme doesn't quite match my system colors, but it would be super awesome to not have each new tab blind me. :)

I run Nightly, so happy to test any patches that land, and if there's any other way I can help move this bug along, let me know.

On Windows 10 with system dark mode enabled, Firefox was running Dark theme but about:home was showing as white. However toggling to any other theme and then back to dark theme seemed to fix the issue - until Firefox is restarted. Both explicit dark mode and default make rest of Firefox skinned to use dark theme (so it follows system settings). But as others stated - about:home does not seem to follow this and any temp fixes are dropped at browser restart.

ke5trel, do you intend to get back to this or should it be unassigned?

Is there anyone who could fix this? I think this would be a good idea to fix in conjunction with Bug 1529323. Right now it's very easy to get into a mode where the UI is dark, but some in-content pages are blinding white.

We probably need some kind of product decision here? The coment in patch D33442 also highlight some of inconsistencies we produced here. Mostly for compatibility with Chrome?

Aside: I am personally annoyed that I have to use the Firefox dark theme to avoid this issue, because the title-bar color doesn't match with my GTK theme...

(In reply to Tom Schuster [:evilpie] from comment #20)

Is there anyone who could fix this? I think this would be a good idea to fix in conjunction with Bug 1529323. Right now it's very easy to get into a mode where the UI is dark, but some in-content pages are blinding white.

We could potentially fix this as suggested in D33442 without bug 1529323, but bug 1529323 would get us better consistency overall, so bundling both fixes would make sense. I don't think it's particularly difficult to pull off, we just need someone to make it their project. Recently it seemed like a Thunderbird engineer might pick up bug 1529323 via bug 1592210.

Especially with Linux GTK themes, Bug 1529323 is the opposite of what we want:

If you're using the "Default" theme (which is basically the system GTK theme) and change your system theme to dark, every theme-respecting website would be light. Other websites (like WhatsApp web), and extensions (like Dark Reader with the "Use system color scheme" option) already work properly and render everything dark. Doing what's suggested in bug 1529323 would just spread this bug to every website and extension instead of just the "about:" pages.

Instead, what's needed is for about:newtab, about:home, about:preferences, etc to use "prefers-color-scheme" to determine if they should be dark or not, independent of what's said in any other bug. They should just behave as the rest of the websites.

The same problem occurs with "Reader View for clutter-free web pages" feature which does not apply dark theme with "dark reader" extension

I can't use my GTK's default theme because of this bug. Enabling the Firefox Dark theme however makes the colors
not match with the rest of GTK. This is a targeted fix for that case by using the default theme's darkTheme
colors for content.

Can you please answer my last question on phab?

(In reply to Tom Schuster [:evilpie] from comment #34)

Can you please answer my last question on phab?

done

Previously a light theme was always used for the newtab page if no
customizations were applied by the active lightweight theme. This change instead
respects the prefers-color-scheme media query in that situation, making it more
consistent with other content pages.

With the changes in part 1, the newtab page would now be rendered with a dark
theme if the user has prefers-color-scheme: dark due to OS styling, but
explicitly selects the provided "Light" theme.

This patch explicitly specifies the text and background colors in the "Light"
theme, ensuring that the newtab page will always be rendered with a light
colorscheme if the "Light" theme is selected, which is more in-line with the
previous behaviour and consistent with the built-in "Dark" theme.

With the changes in part 1, the default behaviour for the newtab page is based
on the value of prefers-color-scheme, rather than always defaulting to a light
theme.

As this should produce the correct behaviour in places where the default theme's
dark_theme variant is currently used, this patch removes custom newtab styles
from the default theme entirely.

Previously due to the decision to use native styles on linux in the parent
process, we would always ignore the dark_theme variant provided Lightweight
Themes, in order to ignore the overrides used by the default theme. This changes
that logic to respect dark_theme variants for all non-default themes on Linux,
bring it closer to feature parity with other platforms.

https://hg.mozilla.org/mozilla-central/rev/677b943b54d9
https://hg.mozilla.org/mozilla-central/rev/04e63023b6e8
https://hg.mozilla.org/mozilla-central/rev/69785e213145
https://hg.mozilla.org/mozilla-central/rev/03c5e8aa1f99

I have verified that the "about:home", and the "about:newtab" pages respect the OS Theme while the "Default" Firefox theme is selected using Firefox Beta 88.0b3 (Build ID: 20210325185929) on Windows 10 x64, macOS 11.2.3, and Ubuntu Linux 20.04 x64.