Previously we were recording enrollment status telemetry everywhere we
were calling into `enroll` and `_unenroll` from onRecipe and
`updateEnrollment`. Now we record the enrollment status telemetry from
inside `NimbusTelemetry.recordEnrollment` and
`NimbusTelemetry.recordUnenrollment`, so that the enrollment status
telemetry is recorded from *every* enrollment event, not just during
`RemoteSettingsExperimentLoader.updateRecipes()`.
To help with this, a new helper has been added, `UnenrollmentCause`,
which carries all the metadata required to unenroll from an experiment
(similar how `CheckRecipeResult` carries all the metadata for enrollment
and updating enrollment) and to submit the corresponding telemetry. Now
instead of calling `unenroll()` with a reason string, you must call it
with an object returned from one of the `UenrollmentCause` utilities.
All tests that were calling `unenroll()` with a string like
"test" or "cleanup" have been updated to remove the reason string. When
it is not present, the `UnenrollmentCause` will default to an "unknown"
reason, which is good enough for test cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D243212
Previously we were recording enrollment status telemetry everywhere we
were calling into `enroll` and `_unenroll` from onRecipe and
`updateEnrollment`. Now we record the enrollment status telemetry from
inside `NimbusTelemetry.recordEnrollment` and
`NimbusTelemetry.recordUnenrollment`, so that the enrollment status
telemetry is recorded from *every* enrollment event, not just during
`RemoteSettingsExperimentLoader.updateRecipes()`.
To help with this, a new helper has been added, `UnenrollmentCause`,
which carries all the metadata required to unenroll from an experiment
(similar how `CheckRecipeResult` carries all the metadata for enrollment
and updating enrollment) and to submit the corresponding telemetry. Now
instead of calling `unenroll()` with a reason string, you must call it
with an object returned from one of the `UenrollmentCause` utilities.
All tests that were calling `unenroll()` with a string like
"test" or "cleanup" have been updated to remove the reason string. When
it is not present, the `UnenrollmentCause` will default to an "unknown"
reason, which is good enough for test cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D243212
This patch does not change the targeting context telemetry as it is
sufficiently complicated and isolated from the rest of the telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D241325
This patch does not change the targeting context telemetry as it is
sufficiently complicated and isolated from the rest of the telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D241325
- Support an on-train limited rollout of the TOS preonboarding modal for platforms where first run experiments are not supported (Mac, Linux, MSIX)
- This patch lands the initial feature work and an uplift in 137 release will enable it for 1% of users. Later in 137, a second uplift will increase the population to 25%.
- Two nimbus features with fallback prefs are available for testing, the fallback prefs are `browser.preonboarding.onTrainRolloutEnabled` and `browser.preonboarding.onTrainRolloutPopulation`.
Differential Revision: https://phabricator.services.mozilla.com/D238304
To support the upcoming TOS preonboarding experiment, we want to ensure the following actions occur sequentially:
- setting prefs, including `datareporting.healthreport.uploadEnabled` (`SET_PREF`)
- submitting the onboarding opt-out ping, if applicable (`SUBMIT_ONBOARDING_OPT_OUT_PING`)
- notifying that the data reporting notification has been interacted with (`DATAREPORTING_NOTIFY_DATA_POLICY_INTERACTED`).
When these actions occur out of order, it is possible for telemetry to be enabled and then disabled. This is likely what accounts for the onboarding-opt-out followed by deletion-request pings witnessed by QA in Bug 1948717.
We believe that the issue is that the `MULTI_ACTION` SMA does not guarantee any ordering of its child actions: see [[ https://searchfox.org/mozilla-central/rev/0d1f8ff61fe506646fe3898ef727817b4436ab32/toolkit/components/messaging-system/lib/SpecialMessageActions.sys.mjs#687-696 | here ]]. That's by design, since early actions including pinning and set-to-default, which are slow and can be run concurrently. But here, we expect sequential ordering (and also [[ https://searchfox.org/mozilla-central/rev/0d1f8ff61fe506646fe3898ef727817b4436ab32/browser/components/aboutwelcome/content-src/components/MultiStageAboutWelcome.jsx#578-585 | in the code ]]).
The obvious way to address this is to have the MULTI_ACTION order its child actions. However, this needs to be a flag, since we have existing consumers and we want to minimize disruption.
This patch adds support for an `orderedExecution` flag on message `action` configurations for those with type `MULTI_ACTION`. This applies to nested `MULTI_ACTIONS` using `collectSelect` as well, assuming each `MULTI_ACTION` has the `orderedExecution` flag.
Differential Revision: https://phabricator.services.mozilla.com/D238816
