With the native Gtk LookAndFeel, nsLookAndFeel::ConfigureContentGtkTheme does a couple of things:

• It honors the widget.content.gtk-theme-override pref to use a specific theme
• It enforces a non-dark theme, to avoid dark scrollbars from being shown in light content

We need to do something similar when the headless Gtk LookAndFeel is in use. Which probably means temporarily switching to the alternate theme in the parent process during its own LookAndFeel initialization, and extracting the relevant colors so they can be sent to content processes for the headless LookAndFeel to use.

Tracking for Fission Beta milestone (M7) because we'd like to include Linux in our Beta experiment.

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

When the RemoteLookAndFeel is not in use, content processes override the
Gtk theme in some circumstances (e.g. if the theme is a dark variant, we
try choosing the light one, since that works better with Web content).

When the RemoteLookAndFeel is in use, the parent process needs to handle
this. So we temporarily set the parent process to the overridden theme,
extract the FullLookAndFeel data, then restore the original theme. We
make sure to avoid throwing away any cached data and restyling every
document as a result of the temporary theme change.

Writing down some options considered here, but not used:

gtk_css_provider_get_named() looked useful, but the gtk_style_context_add_provider* methods would cascade in priority to the provider for the system theme, and there appears to be no way to identify the provider for the system theme in order to remove it.

Intercepting GdkEventSetting and using gdk_screen_get_setting() might support dynamic theme changes after g_object_set(), but this would be clumsy and only be useful for the diminishing proportion of users who have not updated to GTK 3.20 or newer but do change their theme.

This avoids us doing the full work of ExtractData every time a new content
process is created. That work is probably not super expensive, but without
this caching it does trip up
browser/base/content/test/performance/browser_preferences_usage.js due to
looking up a non-mirrored pref.

https://hg.mozilla.org/mozilla-central/rev/75e03ceb0417
https://hg.mozilla.org/mozilla-central/rev/133765f936a0