This patch removes the wrapping of the addons-container at all widths, and instead wraps it only at widths < 960 and > 800, which is the range that the contents of the container can overflow if the title of the addon has a very long word in it.
Differential Revision: https://phabricator.services.mozilla.com/D248091
- Make the brand logo element non-selectable.
- As brand logo is used across a number of messaging system surfaces, I've taken the simplest approach here of off adding `-moz-user-select: none;` without changing the structure of the brand logo element.
Differential Revision: https://phabricator.services.mozilla.com/D247165
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
This patch adds functionality to the multiselect component to allow for a "picker" design. The picker design is enabled by adding the `multiSelectDesign` property with a value of `picker` to a tile object of type `multiselect`.
Differential Revision: https://phabricator.services.mozilla.com/D243350
This patch changes the markup of the addons picker in fullscreen onboarding to support new designs, and further alters the addons picker styles to support its use in fullscreen split onboarding screens for future experimentation.
Differential Revision: https://phabricator.services.mozilla.com/D240095
This patch changes some of aboutwelcome's CSS to support the addition of a title and subtitle per content tile. It also adds styles that enable multiple content tiles to be used in onboarding.
Differential Revision: https://phabricator.services.mozilla.com/D239486
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
**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
Enhancements for the embedded browser component in AboutWelcome:
- Improve the speed at which the browser starts by predicting the `remoteType` the load is going to finish in
- Set `maychangeremoteness` attribute to true to allow changing remoteness if user navigates to a different URL that requires this (such as an `about:` page, though with the current set up `about:` pages won't load for security reasons).
- Set `nodefaultsrc` attribute to true to avoid loading a default URL if `src` is blank
Differential Revision: https://phabricator.services.mozilla.com/D232425
* Update nimbus variable and browser-sidebar to avoid resetting pref after experiment end
* Allow use of sidebar visibility as a set pref multi-action from spotlight modal
Differential Revision: https://phabricator.services.mozilla.com/D231387
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
