ExperimentManager.unenroll() is now effectively async when running in a
browser test (because we are now executing SQL queries during
unenrollment) so all cleanup functions that trigger unenrollment are
async as well.
Differential Revision: https://phabricator.services.mozilla.com/D250506
Places frontend initialization is surprisingly complex, and disentangling it
from the rest of startup by moving it to its own file helps make some of the
logic a little more obvious, and makes unit-testing a bit easier.
This also removes BrowserGlue from the indirection mechanism used between
MigatorBase instances and Places, by switching to category-manager-based
invocation - this way, migrator code does not need to directly
call places code to tell it it's done, but we don't need BrowserGlue to play
messenger between them.
It would be nice to do the same thing for `places-init-complete` but
that is notified from C++ code so unfortunately that is not easily possible.
Differential Revision: https://phabricator.services.mozilla.com/D244428
- 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 diff was generated as follows:
List all toml files in the tree:
`find * -name '*.toml' > /tmp/toml`
Manually edited /tmp/toml to drop non-relevant entries (objdir).
Ran the toml linter for all files:
`cat /tmp/toml | xargs ./mach lint -l test-manifest-toml --fix`
Differential Revision: https://phabricator.services.mozilla.com/D240948
This blocks FOG initialization on notifying the user. This **does**
change the existing functionality, even when the Messaging System is
not used to notify the user: in legacy situations, this will display a
background tab and the promise will resolve quickly (not immediately),
falling back to an infobar that might be delayed 10-60s before being
displayed and being resolved (again, not immediately).
(Legacy Telemetry was blocked already, because the existing user
notification blocks sending Legacy Telemetry.)
Finally, the default browser prompt is blocked so that there's no race
between the (potentially blocking) Messaging System notification and
other prompts. This also changes the behaviour by allowing the
Messaging System notification to be resolved and a subsequent
prompt (such as the default browser prompt) to be displayed
immediately afterward.
Differential Revision: https://phabricator.services.mozilla.com/D236624
This partially reverts the changes of an earlier commit, which made
some things asynchronous. The `NimbusFeatures.getAllVariables()` API
is not, in fact, asynchronous, so opening the internals is not
strictly necessary. This simplifies the expression and testing for
later.
N.b.: the existing implementation did not correctly test
`_openFirstRunPage`: that function was async and there was no `await`.
Therefore existing tests were asserting things about the function
definitions and not the function behaviours.
Differential Revision: https://phabricator.services.mozilla.com/D235886
This blocks FOG initialization on notifying the user. This **does**
change the existing functionality, even when the Messaging System is
not used to notify the user: in legacy situations, this will display a
background tab and the promise will resolve quickly (not immediately),
falling back to an infobar that might be delayed 10-60s before being
displayed and being resolved (again, not immediately).
(Legacy Telemetry was blocked already, because the existing user
notification blocks sending Legacy Telemetry.)
Finally, the default browser prompt is blocked so that there's no race
between the (potentially blocking) Messaging System notification and
other prompts. This also changes the behaviour by allowing the
Messaging System notification to be resolved and a subsequent
prompt (such as the default browser prompt) to be displayed
immediately afterward.
Differential Revision: https://phabricator.services.mozilla.com/D236624
This partially reverts the changes of an earlier commit, which made
some things asynchronous. The `NimbusFeatures.getAllVariables()` API
is not, in fact, asynchronous, so opening the internals is not
strictly necessary. This simplifies the expression and testing for
later.
N.b.: the existing implementation did not correctly test
`_openFirstRunPage`: that function was async and there was no `await`.
Therefore existing tests were asserting things about the function
definitions and not the function behaviours.
Differential Revision: https://phabricator.services.mozilla.com/D235886
Add ability to show the preonboarding modal on every startup until a configured "interactionPref" is set to true, typically via interaction with the primary CTA.
Differential Revision: https://phabricator.services.mozilla.com/D234406
- Add `preonboarding` Nimbus feature for showing a window modal over about:welcome that cannot be dismissed via ESC
- Include the ability to suppress showing the privacy notice tab on first run using a variable under the new `preonboarding` feature
- Remove legacy `showModal` related `aboutwelcome` Nimbus feature variables (these are not in use and were for [[ https://experimenter.services.mozilla.com/nimbus/window-modal-vs-tab-modal/summary | an old experiment ]])
Differential Revision: https://phabricator.services.mozilla.com/D234039
- Add `preonboarding` Nimbus feature for showing a window modal over about:welcome that cannot be dismissed via ESC
- Include the ability to suppress showing the privacy notice tab on first run using a variable under the new `preonboarding` feature
- Remove legacy `showModal` related `aboutwelcome` Nimbus feature variables (these are not in use and were for [[ https://experimenter.services.mozilla.com/nimbus/window-modal-vs-tab-modal/summary | an old experiment ]])
Differential Revision: https://phabricator.services.mozilla.com/D234039
This patch updates the logic that prevents about:welcome from showing when the Nimbus `aboutWelcome` `showModal` variable is set to true. If separate screens for the modal are provided, it can now be shown on top of the default onboarding flow in about:welcome.
A `requireAction` variable that sets the modal to be a window modal requiring action (other than pressing ESC) to dismiss is also added to the `aboutWelcome` Nimbus feature
Differential Revision: https://phabricator.services.mozilla.com/D230185
