**Summary**
Adds a card for migrated Review Checker notifying users can move the sidebar to the left or the right side. Visibility is controlled by two factors:
- browser.shopping.experience2023.newPositionCard.hasSeen - if true, the user already saw the card and we don't have to show it again. If false (default), make sure to show the card once we're able to.
- browser.shopping.experience2023.integratedSidebar - must be true, since this enables Review Checker in the sidebar and allows us to use ReviewChecker actors
There's also three actors in play:
**ReviewCheckerManager**
- Responsible for the sidebar's visibility and auto-open behaviour. We only show the notification card on auto-open and a PDP, so we check if we can render the notification card in this file.
- It also handles behaviour for moving the sidebar position, or showing the sidebar settings panel.
- However, because ReviewCheckerManager is instantiated before the ReviewChecker parent and child pair actors, we have to wait for RC parent to be created before RC manager can communicate with it.
**ReviewCheckerParent**
- Once created, it communicates with ReviewCheckerManager, so that we know if we should render the notification card or not.
- If it receives a response back from RC manager, it will send a message to its RC child counterpart.
- Otherwise, if it receives a message from RC child to move the sidebar position or show the sidebar settings panel, communicate with RC manager again to do the appropriate action.
**ReviewCheckerChild**
- It receives a message from ReviewCheckerParent to know if we should show the notification card. If yes, then send an event to the content (shopping-container)
- It also listens for and handles events from content (shopping-container), like if a user presses the move position buttons, or wants to see the sidebar settings panel. Once an event is detected for either action from content, send a message to ReviewCheckerParent, and then RC manager by extension, to make the appropriate action.
**Follow-up work**
There's another patch https://phabricator.services.mozilla.com/D239083 that updates how the notification card and keep closed message behave, ensuring they don't visually conflict with each other.
Differential Revision: https://phabricator.services.mozilla.com/D238089
**Summary**
Adds a card for migrated Review Checker notifying users can move the sidebar to the left or the right side. Visibility is controlled by two factors:
- browser.shopping.experience2023.newPositionCard.hasSeen - if true, the user already saw the card and we don't have to show it again. If false (default), make sure to show the card once we're able to.
- browser.shopping.experience2023.integratedSidebar - must be true, since this enables Review Checker in the sidebar and allows us to use ReviewChecker actors
There's also three actors in play:
**ReviewCheckerManager**
- Responsible for the sidebar's visibility and auto-open behaviour. We only show the notification card on auto-open and a PDP, so we check if we can render the notification card in this file.
- It also handles behaviour for moving the sidebar position, or showing the sidebar settings panel.
- However, because ReviewCheckerManager is instantiated before the ReviewChecker parent and child pair actors, we have to wait for RC parent to be created before RC manager can communicate with it.
**ReviewCheckerParent**
- Once created, it communicates with ReviewCheckerManager, so that we know if we should render the notification card or not.
- If it receives a response back from RC manager, it will send a message to its RC child counterpart.
- Otherwise, if it receives a message from RC child to move the sidebar position or show the sidebar settings panel, communicate with RC manager again to do the appropriate action.
**ReviewCheckerChild**
- It receives a message from ReviewCheckerParent to know if we should show the notification card. If yes, then send an event to the content (shopping-container)
- It also listens for and handles events from content (shopping-container), like if a user presses the move position buttons, or wants to see the sidebar settings panel. Once an event is detected for either action from content, send a message to ReviewCheckerParent, and then RC manager by extension, to make the appropriate action.
**Follow-up work**
There's another patch https://phabricator.services.mozilla.com/D239083 that updates how the notification card and keep closed message behave, ensuring they don't visually conflict with each other.
Differential Revision: https://phabricator.services.mozilla.com/D238089
**Summary**
Adds a card for migrated Review Checker notifying users can move the sidebar to the left or the right side. Visibility is controlled by two factors:
- browser.shopping.experience2023.newPositionCard.hasSeen - if true, the user already saw the card and we don't have to show it again. If false (default), make sure to show the card once we're able to.
- browser.shopping.experience2023.integratedSidebar - must be true, since this enables Review Checker in the sidebar and allows us to use ReviewChecker actors
There's also three actors in play:
**ReviewCheckerManager**
- Responsible for the sidebar's visibility and auto-open behaviour. We only show the notification card on auto-open and a PDP, so we check if we can render the notification card in this file.
- It also handles behaviour for moving the sidebar position, or showing the sidebar settings panel.
- However, because ReviewCheckerManager is instantiated before the ReviewChecker parent and child pair actors, we have to wait for RC parent to be created before RC manager can communicate with it.
**ReviewCheckerParent**
- Once created, it communicates with ReviewCheckerManager, so that we know if we should render the notification card or not.
- If it receives a response back from RC manager, it will send a message to its RC child counterpart.
- Otherwise, if it receives a message from RC child to move the sidebar position or show the sidebar settings panel, communicate with RC manager again to do the appropriate action.
**ReviewCheckerChild**
- It receives a message from ReviewCheckerParent to know if we should show the notification card. If yes, then send an event to the content (shopping-container)
- It also listens for and handles events from content (shopping-container), like if a user presses the move position buttons, or wants to see the sidebar settings panel. Once an event is detected for either action from content, send a message to ReviewCheckerParent, and then RC manager by extension, to make the appropriate action.
**Follow-up work**
There's another patch https://phabricator.services.mozilla.com/D239083 that updates how the notification card and keep closed message behave, ensuring they don't visually conflict with each other.
Differential Revision: https://phabricator.services.mozilla.com/D238089
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
This also ensures we are more consistent about using the state of `SelectableProfileService.isEnabled` to check if the feature is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D236848
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 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
Flip default pref to true and remove featuregate entry/strings/styles. Switch actor enabled to actual opt-in / provider. Update sidebar tests for chatbot as default tool.
Differential Revision: https://phabricator.services.mozilla.com/D233204
This makes the AboutNewTabChild DOMContentLoaded event handler capturing in
order to ensure that it injects the contentTheme.js script before the
LightweightThemeChild fires its LightweightTheme:Set event. This worked
before by virtue of actor registration order (which this patch changes).
Differential Revision: https://phabricator.services.mozilla.com/D234590
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 commit makes the usage reporting preference inherit the general
data reporting preference for existing Firefox users. New Firefox
users will use the default usage reporting preference value, which is
enabled by default. Future onboarding changes will likely impact the
default usage reporting preference value.
Differential Revision: https://phabricator.services.mozilla.com/D232569
This commit "splits the difference", putting as much behaviour as
convenient into a new `UsageReporting` module while still connecting to
`TelemetryControllerParent`. The latter connection keeps testing
consistent; tests can assume that preference listeners, etc, are
registered.
The usage ID is preserved sibling to other client IDs in the "data
reporting state" bundle. In the future, it might make sense to keep
the usage ID only as a Glean metric, but that might require a
migration and some code restructuring. For expedience, I will keep
the existing implementation.
Differential Revision: https://phabricator.services.mozilla.com/D231995
