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
**Primary Updates**
- Add ability to show multiple content tiles on a single AboutWelcome screen by supporting an array of tile objects and/or sub-arrays of tile objects to be groups together as a value for "tiles" in screen content
- Keep compatibility with messages that use a single tile object as the value of "tiles" in screen content
- Add updates to `setMultiSelectActions` to ensure we can handle actions across multiple MultiSelect tiles.
- Add optional tile headers which can be displayed in place of the tile until clicked, closing any other tile with a header that's currently open
- Send click event telemetry when a user clicks a tile header to open the tile
- Update aboutwelcome source docs related to content tiles to include this new capability
**Additional Updates to Support UX Designs**
[[ https://www.figma.com/design/F63Ac1akw2q1fN5D59rgS5/Privacy?node-id=4110-16458&t=kSzPUp4XFLq0dKg8-4 |
See Figma designs ]]
- Add ability to configure `display`, `padding`, and `width` for aboutwelcome screens (this allows us to support the proposed Spotlight modal designs, which include anchoring the modal towards the top of the screen and expanding it downward when a tile is opened, rather than centering vertically)
- Add ability to configure action buttons to show above screen content
{F11717546}
Differential Revision: https://phabricator.services.mozilla.com/D231856
This patch adds an startup idle task that sets the browser as default if an attribution campaign id of "set_default_browser" is present on first run. This works supports an upcoming experiment where users will have the option to "download as default" via [[ https://www.mozilla.org/en-US/firefox/new/ | the stub installer marketing page ]].
Differential Revision: https://phabricator.services.mozilla.com/D225212
This patch adds an startup idle task that sets the browser as default if an attribution campaign id of "set_default_browser" is present on first run. This works supports an upcoming experiment where users will have the option to "download as default" via [[ https://www.mozilla.org/en-US/firefox/new/ | the stub installer marketing page ]].
Differential Revision: https://phabricator.services.mozilla.com/D225212
This patch adds an startup idle task that sets the browser as default if an attribution campaign id of "set_default_browser" is present on first run. This works supports an upcoming experiment where users will have the option to "download as default" via [[ https://www.mozilla.org/en-US/firefox/new/ | the stub installer marketing page ]].
Differential Revision: https://phabricator.services.mozilla.com/D225212
