Closed Bug 1672097 Opened 4 years ago Closed 4 years ago

honor nsLookAndFeel::ConfigureContentGtkTheme when RemoteLookAndFeel is in use

Categories

(Core :: Widget: Gtk, defect)

defect

Tracking

()

RESOLVED FIXED
86 Branch
Fission Milestone M7
Tracking Status
firefox86 --- fixed

People

(Reporter: heycam, Assigned: heycam)

References

Details

Attachments

(2 files)

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.

Fission Milestone: --- → M7
Blocks: 1672013
No longer blocks: linux-nnt
Depends on: 1470983
See Also: → linux-nnt
Summary: honor nsLookAndFeel::ConfigureContentGtkTheme for Linux non-native theme → honor nsLookAndFeel::ConfigureContentGtkTheme when RemoteLookAndFeel is in use
Blocks: 1680175

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.

Assignee: nobody → cam
Status: NEW → ASSIGNED

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.

Attachment #9190716 - Attachment description: Bug 1672097 - Make Gtk theme overrides work with the RemoteLookAndFeel. → Bug 1672097 - Part 1: Make Gtk theme overrides work with the RemoteLookAndFeel.

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.

Pushed by cmccormack@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/75e03ceb0417 Part 1: Make Gtk theme overrides work with the RemoteLookAndFeel. r=spohl,karlt https://hg.mozilla.org/integration/autoland/rev/133765f936a0 Part 2: Cache FullLookAndFeel data. r=karlt
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Regressions: 1683065
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: