This adds a new `advance_screens` pseudo-action to the `feature_callout`
messaging system template, which can be added to any action in the same
way `navigate` is used currently. This should generally be used instead
of `navigate`, which only advances the inner content but not the outer
wrapper, the anchor, the page event listeners, and other state relevant
for panel callouts.
Some callouts want to show even if the `cfr.features` pref is disabled,
such as surveys and important onboarding messages, and hard-coding that
check in FeatureCallout is heavy-handed as we already have better ways
to do it. Most callouts belong to the `cfr` group, which locks them
behind the features pref. Any that can't use groups, like the PDF
annotations callouts, can check the pref directly in their targeting.
Aside from blocking messages that don't want to be blocked by that pref,
it also results in a weird behavior where, if the pref changes while the
callout is still open (pretty unlikely), the callout will hide when you
click "next" instead of advancing to the next screen. If you clicked the
Next button, it should show you the next screen, even if you somehow
blocked the message by pref before clicking.
So it's cleaner to just let ASRouter handle that in the targeting phase.
If the pref changes while a message is showing, then we'll just leave it
open, and it won't apply until targeting is checked.
It's appropriate to make the change here, because this patch adds a new
screen advancement scheme, separate from the tour pref system. Since
we're reproducing the advancement logic, we're forced to decide whether
to reproduce the feature pref check in this new scheme. I realized 99%
of the time it's doing nothing, and in the rare cases where it does have
an effect that differs from the regular pref targeting, it's a negative
effect. And at that point, we might as well rip the bandaid off all at
once, to keep everything consistent.
Additionally, while adding documentation for this new feature, I also
corrected some existing errors in the documentation.
Differential Revision: https://phabricator.services.mozilla.com/D229084
- 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
We want to capture the default state of multiselect checklist items when a user clicks the primary CTA on an aboutwelcome screen, even if the checklist hasn't been rendered yet (such as when the user needs to click a button to toggle it in to view).
Differential Revision: https://phabricator.services.mozilla.com/D237773
