- Show ToS modal by default for all new users on official builds
- Remove code related to the on-train rollout for Mac/Linus/MSIX
Differential Revision: https://phabricator.services.mozilla.com/D247111
This converts `ExposureSuggestions` to `DynamicSuggestions`. Dynamic Rust
suggestions can be used to deliver hidden-exposure suggestions. I updated the
exposure test to show that, and I also added a new dynamic test.
Differential Revision: https://phabricator.services.mozilla.com/D244466
- Show ToS modal by default for all new users on official builds
- Remove code related to the on-train rollout for Mac/Linus/MSIX
Differential Revision: https://phabricator.services.mozilla.com/D245100
The set of changes included in this patch includes:
- all special handling related to colorway builtin themes removed from AddonManager and XPIProvider,
besides the AddonWrapper getter named isBuiltinColowayTheme, because that is still technically being
used by BuiltInThemes.sys.mjs which is part of what this bug is tracking and should be part of
separate changes built on top of the finalized version of this patch
- remove test cases that were covering behaviors that are part of the special handling code being removed
- keeps the test coverage related to the non-colorway builtin themes localization, which is still supported,
- extend the test coverage by adding an explicit test case to verify that if a builtin theme is not
fully removed from a user profile while its fluent strings are already gone, will make the AddonWrapper
getters to fallback to the value set on the manifest property (e.g. user profiles where a colorway
builtin is still retained and failed to migrate to the AMO hosted colorway theme will hit this issue
and so this test coverage ensures that we handle that corner case more gracefully)
At this stage the colorways themes have not been removed from the tree and the BuiltInThemeConfig.sys.mjs,
and so those themes will still load just fine and the migration to an AMO hosted theme is not going to be
happening anymore.
In the patches meant to be completing the Colorways builtin themes cleanups we will have to:
- Remove all colorways builtin themes from BuiltInThemesConfig
- Remove all colorways builtin themes resources from the builds
- (At this stage the colorway theme will not be able to fully load correctly anymore, but for a user profile
where the colorway builtin theme was the active theme the colors associated to the colorway theme are already
stored in the AOM startup data and so the Firefox windows will still be using the expected set of colors
even when the manifest.json file of the builtin colorway theme is not available anymore and cannot be loaded
correctly anymore)
- After the browser startup has been completed, we should them either check if the active theme is still
a builtin colorway theme, and if it is then message the user to let them know that the colorway builtin theme
has been removed and they can install it from AMO if they still want to use that theme, and uninstall the
builtin colorway theme
- (uninstalling the builtin colorway theme explicitly is needed also to clear the remaining bits of that
builtin from the AddonManager startup data and AddonManager DB)
- it may also be worth considering to go through all themes and remove any other colorway theme that is still
builtin and retained as a disabled theme (in the end those cannot be enabled anymore after their manifest
files are not included in the build anymore).
Differential Revision: https://phabricator.services.mozilla.com/D200988
The set of changes included in this patch includes:
- all special handling related to colorway builtin themes removed from AddonManager and XPIProvider,
besides the AddonWrapper getter named isBuiltinColowayTheme, because that is still technically being
used by BuiltInThemes.sys.mjs which is part of what this bug is tracking and should be part of
separate changes built on top of the finalized version of this patch
- remove test cases that were covering behaviors that are part of the special handling code being removed
- keeps the test coverage related to the non-colorway builtin themes localization, which is still supported,
- extend the test coverage by adding an explicit test case to verify that if a builtin theme is not
fully removed from a user profile while its fluent strings are already gone, will make the AddonWrapper
getters to fallback to the value set on the manifest property (e.g. user profiles where a colorway
builtin is still retained and failed to migrate to the AMO hosted colorway theme will hit this issue
and so this test coverage ensures that we handle that corner case more gracefully)
At this stage the colorways themes have not been removed from the tree and the BuiltInThemeConfig.sys.mjs,
and so those themes will still load just fine and the migration to an AMO hosted theme is not going to be
happening anymore.
In the patches meant to be completing the Colorways builtin themes cleanups we will have to:
- Remove all colorways builtin themes from BuiltInThemesConfig
- Remove all colorways builtin themes resources from the builds
- (At this stage the colorway theme will not be able to fully load correctly anymore, but for a user profile
where the colorway builtin theme was the active theme the colors associated to the colorway theme are already
stored in the AOM startup data and so the Firefox windows will still be using the expected set of colors
even when the manifest.json file of the builtin colorway theme is not available anymore and cannot be loaded
correctly anymore)
- After the browser startup has been completed, we should them either check if the active theme is still
a builtin colorway theme, and if it is then message the user to let them know that the colorway builtin theme
has been removed and they can install it from AMO if they still want to use that theme, and uninstall the
builtin colorway theme
- (uninstalling the builtin colorway theme explicitly is needed also to clear the remaining bits of that
builtin from the AddonManager startup data and AddonManager DB)
- it may also be worth considering to go through all themes and remove any other colorway theme that is still
builtin and retained as a disabled theme (in the end those cannot be enabled anymore after their manifest
files are not included in the build anymore).
Differential Revision: https://phabricator.services.mozilla.com/D200988
Note that EARLY_BETA_OR_EARLIER seems to be the way to do this; I don't
see anything in firefox.js that is turned on for only Nightly + full Beta.
Differential Revision: https://phabricator.services.mozilla.com/D245806
This pref has been on in Nightly for a while, but since we're not actively working on turning on translucency, we’re turning it off by default for now. This helps reduce differences between Nightly and release that are created by this pref right now, which should make testing and bug reports more straightforward. Once we finalized how transluceny is supposed to look we can turn this pref back on along with the actual translucency pref.
Differential Revision: https://phabricator.services.mozilla.com/D244061
