Move the data upload pref check into each `sendReport` call instead of checking
only at startup. Also fixup various things in test_dap.js.
Differential Revision: https://phabricator.services.mozilla.com/D243247
Adds the integratedSidebar pref to the `shopping2023` Nimbus feature and separates the enabling prefs for the migrated Review Checker in the main sidebar and the Shopping sidebar.
- Updates `browser.shopping.experience2023.integratedSidebar` to be the only enabling pref for the migrated Review Checker sidebar.
- Prevents `browser.shopping.experience2023.enabled` from disabling the migrate sidebar and uses it as the pref for the ShoppingSidebar actors.
- Removes the `browser.shopping.experience2023.shoppingSidebar` pref as it is no longer needed.
- Updates any tests the used these prefs to the new use.
- Init's the two sidebar differently in `ShoppingUtils` based on the Nimbus prefs.
- Unset the `SidebarController._state.command` when a sidebar tool pref sets it to `visible=false` otherwise it will try to re-open when the sidebar is opened again.
Differential Revision: https://phabricator.services.mozilla.com/D242053
* Update sidebar.main.tools default values and include a migration
* Modify updateDefaultTools in SidebarManager
* Update tests
Differential Revision: https://phabricator.services.mozilla.com/D240903
There's no need to use weak reference while relying on something to keep the
prefs object alive.
Use plain prefs API with strong references.
Differential Revision: https://phabricator.services.mozilla.com/D240792
- add fetch in child process
- DOM parsing only once
- check content-type to be text/html before fetching content
- add custom request header x-firefox-ai so publisher has option to allow/disallow the fetch request
- more fetch safeguards(max content-length) may come in the near future
Differential Revision: https://phabricator.services.mozilla.com/D240654
**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
