We don't need so many wrappers and so on. Similarly we don't need
.menu-right, we can use ::after to draw the arrow.
This makes reasoning about menus a lot easier.
Differential Revision: https://phabricator.services.mozilla.com/D245000
From: Sarah Jamie Lewis <sarah@openprivacy.ca>
When the parental controls service is disabled in a build, the DoH
settings now display the correct stauts when Increased or Max Protection
is enabled.
Previously, selecting either of these options would cause DoH to be
enabled, but the "Status" and "Provider" fields would not be properly
populated, due to a check on the gParentalControlsService causing an
error.
This check is now identical to the same check in DownloadIntegration.sys.mjs
Apply 1 suggestion(s) to 1 file(s)
Co-authored-by: ma1 <giorgio@maone.net>
Differential Revision: https://phabricator.services.mozilla.com/D244850
Please see the bug for the motivation.
This adds a new `SuggestFeature.primaryUserControlledPreference` getter that
returns the feature-specific pref that lets the user toggle on/off the feature.
That way we can add `QuickSuggest.clearDismissedSuggestions()`, which goes
through each feature and clears that pref, and `canClearDismissedSuggestions()`,
which goes through and checks whether there are any prefs that can be cleared.
I also added a couple of notification topics for dismissals that the settings UI
uses to update the disabled state of its Restore button.
All of this will let us more easily move to the Suggest Rust component's
dismissal API too, which we should sooner or later.
Depends on D244865
Differential Revision: https://phabricator.services.mozilla.com/D244866
Without this, in my testing with the previous patch, the scroll alignment on
the initial load of the settings page is incorrect, with the top of the
section being cut off. As this is the situation we care about (first load after
a browser update), fixing it seemed important.
I spent some time trying to work out why layout is changing - presumably
items above the "Browser Layout" section are either appearing or disappearing
in a way that races with the scroll. I could never reproduce on any loads other
than the first one. But then I realized the code here was overly complex and
that it would probably be nicer for items to appear in the middle of the view
rather than the top anyway. Yes, this means that sometimes the relevant header
is _still_ not _exactly_ in the middle, but that seems much less important.
Differential Revision: https://phabricator.services.mozilla.com/D241628
Refactor the setting-group and setting-control a little to support
passing in the Preferences.getSetting function rather pulling it off of
window.
Add basic Storybook stories for setting-group and setting-control.
Differential Revision: https://phabricator.services.mozilla.com/D241130
This adds an initial setting-control web component that can render a
moz-checkbox based setting. This will be controlled by a pref to reduce
any churn on the Settings page while we make changes related to Settings
Redesign 2025.
Differential Revision: https://phabricator.services.mozilla.com/D240402
This is the first change to start moving our settings to a config
approach. These settings are all checkboxes so only checkbox support is
added at this time.
In the future, these settings will be regrouped with other settings in
the Settings Redesign 2025 project. Moving the settings will involve
creating a new config with a different grouping of id/l10n/supportPage
values. It should not require moving any code or markup to move the
settings or convert them to using moz-checkbox rather than XUL checkbox.
Differential Revision: https://phabricator.services.mozilla.com/D240400
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
