Previously, the tests were waiting for the load event, which was being emitted
for the initial about:blank. With the pref enabled, this event is no longer
propagated/fired to the content process. Instead of notifying the content
process that it needs to emit a load event for about:blank, we can instead make
the tests wait for a STATE_STOP event.
Differential Revision: https://phabricator.services.mozilla.com/D126843
Previously, the tests were waiting for the load event, which was being emitted
for the initial about:blank. With the pref enabled, this event is no longer
propagated/fired to the content process. Instead of notifying the content
process that it needs to emit a load event for about:blank, we can instead make
the tests wait for a STATE_STOP event.
Differential Revision: https://phabricator.services.mozilla.com/D126843
Now that we're likely not targeting a 94 dot release anymore, I'd like to go
ahead and rename the `suggest.quicksuggest` pref to
`suggest.quicksuggest.nonsponsored` as we considered doing before. There won't
be a better time to do it.
Depends on D128665
Differential Revision: https://phabricator.services.mozilla.com/D130565
This updates the Privacy pane for the new Firefox Suggest preferences spec.
Please see the spec here: https://mozilla-hub.atlassian.net/browse/SNT-37
The Jira description is a little out of date, and the wording of these new
strings (which are not exposed to localizers) isn't finalized, but I'm told the
structure of the UI is final more or less.
There is also a Figma here: https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest-exploration?node-id=3197%3A55695
We're replacing the current two Firefox Suggest checkboxes with three toggle
buttons. The first two toggle buttons correspond to the existing
`browser.urlbar.suggest.quicksuggest` and
`browser.urlbar.suggest.quicksuggest.sponsored` prefs. However, the second pref
is no longer dependent on the first, and it can be toggled regardless of whether
the first is enabled. The third toggle corresponds to a new pref,
`browser.urlbar.quicksuggest.dataCollection.enabled`. It can also be toggled
independently of the others.
In addition, we're adding an info bar/box below the toggles to explain to the
user the effect of their toggle selection. The text in the box depends on the
state of the toggles. The box itself is hidden when all three toggles are off.
Depends on D129224
Differential Revision: https://phabricator.services.mozilla.com/D128661
When switching to an already open but lazy/unloaded about:preferences tab and
highlighting a section in it, wait for it to load first.
Differential Revision: https://phabricator.services.mozilla.com/D125628
The test browser_contentblocking.js needs to be updated to reflect the
change that we no longer set pref in the ETP custom mode.
Differential Revision: https://phabricator.services.mozilla.com/D124904
Per spec, the informational description about data collection under the main
Firefox Suggest checkbox should be hidden except for the "online" scenario,
since only the online scenario sends data to Mozilla.
We're also changing the two checkbox labels and adding another description under
the sponsored checkbox.
Depends on D125024
Differential Revision: https://phabricator.services.mozilla.com/D125031
Enable the Firefox Suggest "offline" scenario by default for users in the US
region with en-* locales.
Previously we relied on Nimbus to enable the offline scenario, and the goal here
is to make it permanent for all users in the US `home` region using en-* locales
so that we don't need Nimbus for it anymore.
With Nimbus, there were two essential mechanisms that restricted the scenario to
the desired population: the `browser.urlbar.quicksuggest.enabled` pref, which is
a global toggle for Firefox Suggest suggestions regardless of region and locale,
and a Nimbus recipe that enabled the pref for US en-* users only.
Without Nimbus, we have only the `browser.urlbar.quicksuggest.enabled` pref. We
can't rely on a server-side solution to target a specific population, so we need
to do it in the client. This patch keeps the default `false` value of
`browser.urlbar.quicksuggest.enabled` in firefox.js, and then it sets a new
default-branch value for the pref for the US en-* population on app startup.
There's actually a set of prefs related to the offline scenario that need to be
set, not only `browser.urlbar.quicksuggest.enabled`.
Depends on D124943
Differential Revision: https://phabricator.services.mozilla.com/D125024
This implements the spec in https://mozilla-hub.atlassian.net/browse/SNT-26, but
Natalie and I have made some tweaks over Slack that aren't reflected in that
ticket.
We want to move the Firefox Suggest preferences from the Search pane to the
Address Bar section of the Privacy pane. There are now two Firefox Suggest
checkboxes instead of one: a main one that enables Firefox Suggest suggestions
and another one that enables sponsored suggestions separately. If the main one
is checked but the sponsored one isn't, then the user will see only
non-sponsored suggestions.
I renamed and modified the browser_searchQuickSuggest.js test I added in
D105701, but a lot of the test changed and it's probably not helpful to look at
the diff against the old version.
Previously strings were hardcoded in search.js. I've added the new ones to the
new preview Fluent file for Firefox Suggest.
Depends on D124300
Differential Revision: https://phabricator.services.mozilla.com/D124431
The test overwrites a fluent-originating text content with its own,
but doesn't clear the fluent data-l10n-id attribute. As a result,
if it tries to write the textContent before the data-l10n-id pass
from fluent has run, fluent overwrites the textContent before we
do a search, and then the rest of the test gets bogus results
because it matches against the wrong text content.
This patch fixes this by removing the data-l10n-id attribute so
the fluent pass doesn't try to put text in these elements
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D122659
We treat clicking "Accept" as a user-choice even if no settings were changed.
We should persist both the TRR mode and URI that were visible in the dialog
at the time of acceptance of the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D119877
We treat clicking "Accept" as a user-choice even if no settings were changed.
We should persist both the TRR mode and URI that were visible in the dialog
at the time of acceptance of the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D119877
