We've made a few changes to this "Top pick" checkbox recently based on shifting
Product requirements, and the problem here is that the checkbox used to be
inside the Firefox Suggest container, but we recently moved it outside the
container. The Firefox Suggest container is properly hidden or shown depending
on whether the Suggest feature is enabled, so when the checkbox was inside the
container and Suggest was disabled, the checkbox properly got hidden too. Now
that the checkbox is outside that container, its visibility needs to entirely
depend on whether the best match feature is enabled.
So all this revision does is move the checkbox's `hidden` assignment from inside
the "is Suggest enabled" if-block to outside the if-block. It also sets
`hidden=true` on the checkbox in the markup for good measure.
I also improved the test so it checks every combination of enabled statuses
between the Suggest and best match features.
Depends on D138987
Differential Revision: https://phabricator.services.mozilla.com/D139161
We've made a few changes to this "Top pick" checkbox recently based on shifting
Product requirements, and the problem here is that the checkbox used to be
inside the Firefox Suggest container, but we recently moved it outside the
container. The Firefox Suggest container is properly hidden or shown depending
on whether the Suggest feature is enabled, so when the checkbox was inside the
container and Suggest was disabled, the checkbox properly got hidden too. Now
that the checkbox is outside that container, its visibility needs to entirely
depend on whether the best match feature is enabled.
So all this revision does is move the checkbox's `hidden` assignment from inside
the "is Suggest enabled" if-block to outside the if-block. It also sets
`hidden=true` on the checkbox in the markup for good measure.
I also improved the test so it checks every combination of enabled statuses
between the Suggest and best match features.
Depends on D138987
Differential Revision: https://phabricator.services.mozilla.com/D139161
This is based on part 1 in D138583. It hides the best match toggle switch when
the best match feature is disabled. The best match feature is a sub-feature of
Firefox Suggest, so the toggle is also hidden if Suggest is disabled, along with
all the other Suggest UI.
Depends on D138583
Differential Revision: https://phabricator.services.mozilla.com/D138584
- Show data collection section in about:preferences#privacy when privacy segmentation
section is enabled.
This is to ensure we can always show the privacy segmentation checkbox, even if data
reporting is disabled.
- Add checkbox and learnMore label for privacy segmentation pref.
- Add pref for section visibility and learnMore link suffix.
- Provisional copy, final copy to be added in Bug 1752172.
Differential Revision: https://phabricator.services.mozilla.com/D136650
- Show data collection section in about:preferences#privacy when privacy segmentation
section is enabled.
This is to ensure we can always show the privacy segmentation checkbox, even if data
reporting is disabled.
- Add checkbox and learnMore label for privacy segmentation pref.
- Add pref for section visibility and learnMore link suffix.
- Provisional copy, final copy to be added in Bug 1752172.
Differential Revision: https://phabricator.services.mozilla.com/D136650
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
This reworks the fix to bug 1729776.
Currently Nimbus doesn't have a way to force the two suggestions prefs [1] on or
off. That might seem surprising since we've run experiments already. Initially
we defaulted the two prefs to true but we defaulted the separate feature-gate
pref [2] to false, and it was the feature-gate pref we controlled via Nimbus. At
some point we changed the defaults to false and then in Firefox flipped them to
true after showing the onboarding dialog. As a result we've never needed to
override the two suggestion prefs via Nimbus.
The problem now is that we default-enable offline (for US en users), so we set
all three prefs to true. For the online rollout, we need to keep the
feature-gate pref enabled but disable the suggestion prefs, and there's no way
to do that.
My first idea was to add new Nimbus variables to override the two suggestion
prefs. The prefs would keep their default true values but be overridden by
Nimbus. But that doesn't work because there's no way for Firefox to tell whether
the prefs are true because the user has opted in (overriding Nimbus) or because
they still have their default values. Setting the prefs to true on the user
branch doesn't have any effect because they're also true on the default branch.
Or maybe there's a way I don't know about to force them to true on the user
branch, but even if there were, it seems brittle to rely on a value being set on
the user branch to distinguish between the two cases. (This is a potential
problem for any prefs that are controlled by both Nimbus and the user. So far
the prefs we've been using via Nimbus have all been hidden feature-gate-type
things and implementation details.)
We already have a `quickSuggestScenario` variable. We currently use it only to
tell what we should send in the telemetry ping (bug 1729576) and whether some
parts of the prefs UI should be shown. This revision makes it much more
important by treating it as the source of truth for the user's scenario. It now
determines the default values of related prefs, including the two suggestions
prefs.
The logic is:
```
If quickSuggestScenario is non-null:
scenario = quickSuggestScenario
Else (e.g., there's no rollout):
If the user is US en:
scenario = offline
Else:
scenario = history
```
After determining the scenario, it's set it as
`browser.urlbar.quicksuggest.scenario` on the default branch. There's an
existing pref observer in UrlbarPrefs, and I added a case for this pref so that
when it's updated we also update all the other prefs that depend on the
scenario. This way when the pref is set -- either due to Nimbus update or by
changing it on about:config -- all the other prefs stay in sync.
I kept the default value of `browser.urlbar.quicksuggest.scenario` but removed
it as the fallback for `quickSuggestScenario`. If it still both had a default
and remained the fallback, then it would be impossible to tell when Nimbus is
trying to override it, because any fetch of the value from Nimbus would just
return the fallback pref's value if there is no override.
I considered instead removing the default value and keeping it as the fallback.
The drawback of that is that unenrollments would not take effect until restart.
I actually tried this approach first, and in tests, after mock experiments were
unenrolled, the pref values remained what they were when the experiment was
active.
It might also be possible to not have the `browser.urlbar.quicksuggest.scenario`
pref at all. We could call NimbusFeatures directly to get the scenario. However,
currently we cache and access Nimbus variables through UrlbarPrefs, as we do
with prefs, and I don't want to add an inconsistency.
This revision also fixes bug 1730596 since it was easy to do given that I needed
a way to prevent indirect recursive updates to the scenario, and I can use that
for bug 1730596 too (the `_updatingFirefoxSuggestScenario` bool).
[1] `browser.urlbar.suggest.quicksuggest` and `browser.urlbar.suggest.quicksuggest.sponsored`
[2] `browser.urlbar.quicksuggest.enabled`
Differential Revision: https://phabricator.services.mozilla.com/D125511
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
UnifiedComplete must stick around to serve as an mozIPlacesAutoComplete implementation for XUL consumers like search.js and privacy.js.
Differential Revision: https://phabricator.services.mozilla.com/D119306
This patch modifies the current CookieJarSettings::Create() function.
It removes the current function and adds two variants. One takes the
nsIPrincipal as input and another takes the enum value. The new
functions will test if the input is for the private browsing window to
create the corresponding cookieJarSettings.
Differential Revision: https://phabricator.services.mozilla.com/D109045
