Closed Bug 1740518 Opened 2 months ago Closed 2 months ago

Websites that don't specify background-color become unreadable when ui.systemUsesDarkTheme=1 and widget.gtk.allow-gtk-dark-theme

Categories

(Core :: Widget, defect, P4)

Firefox 95
Desktop
Linux
defect

Tracking

()

VERIFIED FIXED
96 Branch
Tracking Status
firefox95 --- verified
firefox96 --- verified
firefox97 --- verified

People

(Reporter: lae, Assigned: emilio)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

  1. create new profile using 95.0b4
  2. set ui.systemUsesDarkTheme=1 in about:config
  3. visit a website that sets foreground color of text but not an overall background color, e.g. https://awesomeopensource.com/projects and https://www.hailpixel.com/

Actual results:

Background color is set to #1c1b22, but foreground color is not modified. This color appears to be controlled by the setting browser.display.background.dark, which I think was introduced in https://phabricator.services.mozilla.com/D129746 (this issue does not exist in the previous version I used, 94.0b6-1)

Expected results:

I'm not sure what the right thing to do here is, but these websites and I'm sure a nontrivial number of others should still remain readable. There is a "Dark Reader" extension that I also use and when I enabled it for these websites, it overrode the foreground colors appropriately, which I guess might be preferable but might incur an excessive rendering burden? Otherwise, just sticking to the regular white background (browser.display.background) should suffice for these situations.

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Product: Firefox → WebExtensions

Just a correction, it occurs on hailpixel.com if JS is disabled (alternatively, if you remove the <canvas id="Halo"> element that covers the background).

A couple of other sites that are affected:

https://www.state.gov/covid-19-recovery/
https://hrmos.co/pages/dwango (employment site, pretty much every company's page looks like this)

Here are two cases where the opposite happens, background color is set but foreground is not, which results in white text on white background:

https://puck.nether.net/mailman/listinfo/outages
https://developer.mozilla.org/en-US/docs/Tools (see navigation area)

I expect that most mailman mailing lists also suffer from this, a quick check at proxmox' shows the same behaviour.

Component: Untriaged → Layout
Product: WebExtensions → Core

I can't see any difference in those pages when setting that about:config flag, the web pages still render with a light background.

Can you test with Firefox Nightly? https://nightly.mozilla.org/

Flags: needinfo?(lae)

Tested on Nightly and can't reproduce it there. I also can't reproduce it on a fresh profile on 95.0b10 with the steps I provided previously, now (but my primary profile seems to still be affected, I guess I'll try to figure out what's wrong there).

Flags: needinfo?(lae)

Okay, I was able to reproduce this on Nightly.

In addition to setting ui.systemUsesDarkTheme to 1, widget.content.allow-gtk-dark-theme needs to be set to true to trigger this behaviour.

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jwatt)

Yeah, so two things:

  • You don't want to override ui.systemUsesDarkTheme. You probably want layout.css.prefers-color-scheme.content-override.
  • widget.content.allow-gtk-dark-theme has rather undesirable side-effects and we should remove the special cases for it now that we've shipped color-scheme support everywhere.

See the comments as for why. If as a user you want to get this behavior
you could put something like:

:root { color-scheme: light dark }

in a user stylesheet, but that could cause the same contrast issues the
allow-gtk-dark-theme pref has now.

Assignee: nobody → emilio
Severity: -- → S3
Flags: needinfo?(jwatt)
Priority: -- → P4
Summary: Websites that don't specify background-color become unreadable when ui.systemUsesDarkTheme=1 → Websites that don't specify background-color become unreadable when ui.systemUsesDarkTheme=1 and widget.gtk.allow-gtk-dark-theme
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c4c2b66caca6
Remove allow-gtk-dark-theme special-case in color-scheme computation. r=mstange
Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch
QA Whiteboard: [qa-96b-p2]
Duplicate of this bug: 1745607

Comment on attachment 9252844 [details]
Bug 1740518 - Remove allow-gtk-dark-theme special-case in color-scheme computation. r=mstange

Beta/Release Uplift Approval Request

  • User impact if declined: Bad contrast in some websites with some pref enabled. It'd be good to get this on a dot release because apparently a bunch of people hit this and it's confusing. I think some Linux distro (Manjaro?) may have shipped with that pref enabled?
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce:
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Removes a special case for a pref that is no longer needed and causes more issues than it fixes.
  • String changes made/needed: none
Attachment #9252844 - Flags: approval-mozilla-release?
Flags: qe-verify+
QA Whiteboard: [qa-96b-p2] → [qa-triaged]

I think some Linux distro (Manjaro?) may have shipped with that pref enabled?

I should note that I didn't recall manually setting widget.content.allow-gtk-dark-theme myself, only the ui preference. I was reproducing this on Arch, which Manjaro is based on (and I think they just use Arch's package directly because I can't find it in their repository).

I didn't find any reference to that preference in the packaging instructions, though; all it really does is use a tarball from mozilla.org and just patch a few things: https://github.com/archlinux/svntogit-packages/tree/packages/firefox/trunk (PKGBUILD's the main file).

I was able to reproduce the issue on Firefox 95.0b4 under Ubuntu 20.04 by following the STR from Comment 0 and Comment 5.

The issue is fixed on Firefox 96.0b4 and Firefox 97.0a1 (2021-12-13) on the same system.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

Comment on attachment 9252844 [details]
Bug 1740518 - Remove allow-gtk-dark-theme special-case in color-scheme computation. r=mstange

Approved for a 95 dot release, thanks.

Attachment #9252844 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified on 95.0.1 dot release under Ubuntu 20.04 and the issue is fixed.

Component: Layout → Widget
OS: Unspecified → Linux
Hardware: Unspecified → Desktop
You need to log in before you can comment on or make changes to this bug.