I verified that this fixes the problem in this bug and does not regress
bug 1928064.
The problem was that if only one request was being made with the same
user action ID, the otherEntries would always be empty, and so we would
not show the dialog. Now we handle multiple requests by removing their
info from requestTokenToRequestInfo, and thus when we get the
"dlp-request-made" notification we will exit early and not show a dialog.
Differential Revision: https://phabricator.services.mozilla.com/D239755
This moves l10n strings related to AMP and Wikipedia suggestions out of
`enUS-searchFeatures.ftl` into the appropriate l10n files in preparation for AMP
and Wikipedia in non-U.S. regions. These strings include:
* The result menu item strings, Dismiss and Manage
* Relevant settings UI strings
`urlbar-result-menu-learn-more-about-firefox-suggest` isn't actually used by AMP
and Wikipedia right now, but it was in the past, and there have been recent
discussions about maybe including it again as Suggest expands outside the U.S.
So I moved it too in case we need it with short notice.
There are other Suggest strings that this patch does not move, in particular:
* `-firefox-suggest-brand-name` is already exposed to localizers
* The "Sponsored" label at the bottom of AMP urlbar rows is already exposed to
localizers as `urlbar-result-action-sponsored`
* Strings for the online toggle switch in the settings UI ("Improve the Firefox
Suggest experience") aren't needed right now because online Suggest (Merino)
won't be available outside the U.S. in the near future.
I changed the ID of the Dismiss string so it doesn't include "firefox-suggest".
Several non-Suggest urlbar results use this string too, and it doesn't actually
include the phrase "Firefox Suggest" anyway.
I also made the view default to this string so that dismissable urlbar results
don't need to specify it, similar to how it defaults to strings for "Learn more"
and Manage.
Depends on D238847
Differential Revision: https://phabricator.services.mozilla.com/D239213
This makes the following primary changes to the Suggest settings in the search
pane:
* Remove the infobox
* Remove the learn-more link from the dismissed-suggestions description
* Add a learn-more link to the Address Bar section's description but show it
only when Suggest is enabled
* Add `#w_what-setting-is-opt-in` fragment to the learn-more URL for the online
toggle so it links directly to the appropriate section
It also makes these related changes:
Remove the unnecessary `vbox` containers for the toggle switches. I had to
modify some reusable-components CSS. Note that there are two copies of the
Suggest toggle, one in the search pane and one in the privacy pane.
Rename the sponsored and nonsponsored checkbox strings so they're consistent
with the other checkbox strings: `addressbar-locbar-foo-option`
Remove test tasks that click checkboxes and make sure the appropriate prefs are
updated and vice versa. Now that the infobox is gone, there's no need for
Suggest-specific tests to worry about that.
Similarly, remove test tasks that click the learn-more links and make sure the
right page is opened. No need for Suggest-specific tests to do that either.
Differential Revision: https://phabricator.services.mozilla.com/D238847
**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 is an initial patch with the message bar styled as we would like,
but it is using temporary strings directly in the markup. These will
need to be extracted to fluent strings in a follow up change.
Differential Revision: https://phabricator.services.mozilla.com/D239026
We are no longer using the grouping by BrowsingContext functionality,
so rename and greatly simplify this class. (not strictly needed for this
change, but simpler is better!)
Differential Revision: https://phabricator.services.mozilla.com/D239397
