In order to avoid duplication use the content property, which needs a
trivial change to frame construction to allow to use it for menu icons.
Differential Revision: https://phabricator.services.mozilla.com/D249245
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 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
The preferences initialization code will take care of showing and hiding
this for us when loading different panes - it's the `data-hidden-from-search`
attribute removal that's allowing us to show the group when the preference
is enabled.
The existing test_preferences_visibility test under
browser/components/backup/test/browser/browser_settings.js tests that we
haven't regressed showing and hiding behaviour for the pref.
Differential Revision: https://phabricator.services.mozilla.com/D215806
Use the new API addition to Document portal allowing clients to get real
path to the exported document. This allows to still use the same path as
provided by the document portal, but display the path as exists on the
host side.
Differential Revision: https://phabricator.services.mozilla.com/D202717
Use the new API addition to Document portal allowing clients to get real
path to the exported document. This allows to still use the same path as
provided by the document portal, but display the path as exists on the
host side.
Differential Revision: https://phabricator.services.mozilla.com/D202717
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
