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
