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
browser_genai_init.js is currently failing due to expecting Firefox Labs
to always render in about:preferences. However, now that it is driven by
Nimbus, it only render if we know about any opt-in experiments. Since
the test doesn't create any, Firefox Labs doesn't render and the test
fails.
However, the test only waits for an observer notification and stubs out
that actual implementation that builds the page. If we emit this
notification when we decide not to render Firefox Labs then the test
will fail.
This will be removed in bug 1951311.
Differential Revision: https://phabricator.services.mozilla.com/D240112
This makes the following primary changes to the Suggest settings in the search
pane:
* Remove the infobox
* Remove the learn-more link from the dismissed-suggestions description
* Add a learn-more link to the Address Bar section's description but show it
only when Suggest is enabled
* Add `#w_what-setting-is-opt-in` fragment to the learn-more URL for the online
toggle so it links directly to the appropriate section
It also makes these related changes:
Remove the unnecessary `vbox` containers for the toggle switches. I had to
modify some reusable-components CSS. Note that there are two copies of the
Suggest toggle, one in the search pane and one in the privacy pane.
Rename the sponsored and nonsponsored checkbox strings so they're consistent
with the other checkbox strings: `addressbar-locbar-foo-option`
Remove test tasks that click checkboxes and make sure the appropriate prefs are
updated and vice versa. Now that the infobox is gone, there's no need for
Suggest-specific tests to worry about that.
Similarly, remove test tasks that click the learn-more links and make sure the
right page is opened. No need for Suggest-specific tests to do that either.
Differential Revision: https://phabricator.services.mozilla.com/D238847
This replaces `quickSuggestHideSettingsUI` with `quickSuggestSettingsUi`. Like
the old variable, we can show or hide all Suggest settings UI, and now we can
also hide UI that pertains only to Suggest online. This is necessary because as
we start to roll out Suggest to more regions, online (Merino) won't be available
for them initially.
Differential Revision: https://phabricator.services.mozilla.com/D238159
This replaces `quickSuggestHideSettingsUI` with `quickSuggestSettingsUi`. Like
the old variable, we can show or hide all Suggest settings UI, and now we can
also hide UI that pertains only to Suggest online. This is necessary because as
we start to roll out Suggest to more regions, online (Merino) won't be available
for them initially.
Differential Revision: https://phabricator.services.mozilla.com/D238159
