1683204 - Widget elements in the content process now rendering in a dark theme

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Tom S. (please needinfo tschuster)]

I use a dark GTK system theme. For rendering of elements like <input> in web pages Firefox however used to use some light theme variant.

One of the bugs in this range regressed that.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26bbc0bbde6939815823c299365fb6a6a8fb3da3&tochange=12f20df84a54b6d59b35babad06e57dd7ab3417e

Comment 1

[Tom S. (please needinfo tschuster)]

Attachment: screenshot hg.mozilla.org search box

Comment 2

[Anders Kaseorg]

Same problem for me, with a consistent regression range (2020-12-16-09-36-04 is good, 2020-12-16-21-48-34 is bad).

At the same time, @media (prefers-color-scheme: dark) stopped matching, so pages such as this Bugzilla unexpectedly switched from dark mode to light mode. It would make sense for this to have a common cause: Firefox must now think my Adwaita-dark theme is light.

Comment 3

[Cameron McCormack (:heycam)]

Thanks for the report.

There was a prefers-color-scheme problem, fixed now in bug 1683026. It's possible this problem also affects prefers-color-scheme too.

Anyway, I just tried with the system set to Adwaita-dark (set in gnome-tweaks), and can reproduce, if the widget.disable-native-theme-for-content pref disabled.

I will take a look at the underlying problem tomorrow, but I'll land a change to turn off the pref for the regressing bug now.

Comment 4

[Cameron McCormack (:heycam)]

Attachment: Bug 1683204 - Disable the RemoteLookAndFeel for regressing dark Gtk themes when the non-native theme is not enabled.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/06a291ba4e87
Disable the RemoteLookAndFeel for regressing dark Gtk themes when the non-native theme is not enabled.

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/06a291ba4e87

Comment 8

[Cameron McCormack (:heycam)]

So I think if we want the RemoteLookAndFeel to be usable when the non-native theme has not been enabled, then RemoteLookAndFeel::NativeInit needs to call into nsLookAndFeel::ConfigureContentGtkTheme, so that widget painting uses the right theme.

Comment 10

[Cameron McCormack (:heycam)]

Attachment: Bug 1683204 - Include content theme configuration details in FullLookAndFeel.

And re-enable the RemoteLookAndFeel by default with Gtk.

When the RemoteLookAndFeel is enabled and the non-native theme is not
enabled, we still need to configure the Gtk theme in content processes,
since we're still using Gtk to paint widget backgrounds etc. Without
this, we can end up using LookAndFeel colors from a light theme but
painting widget backgrounds from a dark theme.

Other platforms don't configure themes for content processes
differently, so on those platforms LookAndFeelTheme is an empty struct
and we skip the ConfigureTheme call.

Comment 11

[Cameron McCormack (:heycam)]

https://treeherder.mozilla.org/jobs?repo=try&revision=b3b6ccd43cc668e9c66f562579f9c60b7f95eaa9

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/740e282b9000
Include content theme configuration details in FullLookAndFeel. r=spohl

Comment 13

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/740e282b9000

Comment 14

[Andra Esanu (needinfo me)]

== Change summary for alert #28260 (as of Mon, 28 Dec 2020 08:09:52 GMT) ==

Improvements:

Ratio	Suite	Test	Platform	Options	Absolute values (old vs new)
9%	Base Content Heap Unclassified		linux1804-64-shippable		4,002,296.67 -> 3,643,805.33
9%	Base Content Heap Unclassified		linux1804-64-shippable-qr		4,043,851.33 -> 3,684,823.33
8%	Base Content Heap Unclassified		linux1804-64-shippable-qr		4,013,857.33 -> 3,684,823.33
4%	Base Content Explicit		linux1804-64-shippable		9,958,741.33 -> 9,562,112.00
4%	Base Content Explicit		linux1804-64-shippable-qr		9,999,530.67 -> 9,626,794.67
3%	Base Content Resident Unique Memory		linux1804-64-shippable		16,457,130.67 -> 16,007,338.67
2%	Heap Unclassified		linux1804-64-shippable		69,184,272.07 -> 67,548,813.50

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28260

Comment 15

[Danny Colin [:sdk]]

Attachment: light-scrollbar-with-dark-theme.png

This change also removed the theming of the main scrollbar and now it uses the light theme colors even if the dark theme is enabled. Is it possible to only paint the scrollbar if non-native dark theme is used?

Comment 16

[Cameron McCormack (:heycam)]

Emilio, can you make a decision re comment 15 here?

Comment 17

[Emilio Cobos Álvarez [:emilio]]

What do you mean with "is it possible to only paint the scrollbar if non-native dark theme is used?"

We need to paint an scrollbar, somehow :-)

But yeah, file a bug about this and ni? me, probably we should implement the same kind of scrollbar darkening that Windows has on Linux, if there's a native dark theme we have a place to pull the values from, even.