This moves a handful of things to run slightly later, but primarily it makes
sure that the scheduling and conditions under which each bit of telemetry is
collected is clear and in one place, instead of spread around.
Differential Revision: https://phabricator.services.mozilla.com/D244421
This moves all startup telemetry gathering into a separate file, to prepare
for some minor scheduling changes and avoid all the direct dependencies from
BrowserGlue.sys.mjs.
Note that the status quo in terms of scheduling (which this patch is not
changing, and the next patch in the stack only changes a tiny bit) suggests that
some of the scheduling of this startup telemetry is... somewhat haphazard.
We may wish to invest in better primitives to both avoid data collection taking
valuable resources/time on startup, but also offer better guarantees that the
eventual collection contains the data we need. Especially the "best effort"
scheduled items currently do not satisfy the second criteria. Either way this
should be easier with all the relevant code in one place and scheduled in the
same way.
Differential Revision: https://phabricator.services.mozilla.com/D244420
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
