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
The 'allowDuplicateDialogs' option covered up a bug where we had two click event listeners for the
changeBlockListLink. This should fix the duplicate dialog.
However, there seem to be timing issues with the 'allowDuplicateDialogs' option we should look
into as follow up work.
Differential Revision: https://phabricator.services.mozilla.com/D89585
This also updates the behavior of the allowDuplicates check:
Instead of only checking if the top dialog is a duplicate, it will now check the whole stack and
skip the dialog open if a duplicate URL is found.
This fixes an issue where callers could alternate between dialogs to bypass the check.
Differential Revision: https://phabricator.services.mozilla.com/D88422
* Removing front end for the checkbox that allows users disable accessibility services
* Removing already expired telemtry probe for preferences.prevent_accessibility_services
Differential Revision: https://phabricator.services.mozilla.com/D86994
