Closed Bug 1722886 Opened 2 years ago Closed 2 years ago

System theme is incorrect when ui.systemUsesDarkTheme is set differently


(Core :: Widget: Gtk, defect)

Firefox 90



93 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- disabled
firefox90 --- disabled
firefox91 --- disabled
firefox92 --- disabled
firefox93 --- fixed


(Reporter: ke5trel, Assigned: emilio)


(Blocks 1 open bug, Regression)


(Keywords: regression)


(2 files)


  1. Select a dark GTK theme like Adwaita-dark.
  2. Enable the System theme.
  3. Set ui.systemUsesDarkTheme = 0.


Browser uses system theme colors and web content uses light theme like before.


Browser uses light theme colors but with some dark colors that result in low contrast. Some widgets are dark with dark text. Same kind of problem with light GTK theme and ui.systemUsesDarkTheme = 1.

Regression window:

Regressed by Bug 1707957.

This is because this function is getting the pref value, which is lying, rather than the underlying system value...

I guess we could support this without much trouble, but I'd rather add an explicit way of overriding prefers-color-scheme for content, wdyt?

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Assignee: nobody → emilio
Pushed by
Add a way to override prefers-color-scheme for content without messing with widget values. r=stransky
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
See Also: → 1720508
See Also: → 1725917

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

Karl do you think this is worth uplifting? (Since you filed bug 1725917)

Flags: needinfo?(emilio) → needinfo?(karlt)

I think this was a good thing to do, but would be of limited value for an uplift because the user would still need to discover and change preferences.

widget.gtk.alt-theme.dark already exists for a workaround in the meantime. Even though there may be a small advantage in the user having the option of changing the newer pref now rather than changing an existing intermediate pref, the regression has already shipped and so the existing workaround would already be needed. proposes a solution that does not require pref discovery and change.

Flags: needinfo?(karlt)
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.