This hooks up desktop to the dismissal API in the Rust component [1] and removes
`BlockedSuggestions`.
The Rust dismissal API has two ways to dismiss a suggestion: by `Suggestion`
object and by dismissal key. We use the first one for Rust suggestions and the
second one for other suggestions, like Merino. A dismissal key is just an
arbitrary opaque string token stored in the dismissed-suggestions table in the
Rust component. It's up to consumers (like desktop) to use appropriate dismissal
keys for their non-Rust suggestions.
In order to retain the user's blocked digests that desktop has always recorded
in the `quicksuggest.blockedDigests` pref, I took advantage of dismissal keys by
migrating each digest to a dismissal key in the Rust component.
[1] See bug 1961412 and https://github.com/mozilla/application-services/pull/6714
Differential Revision: https://phabricator.services.mozilla.com/D246369
Nimbus now supports co-enrollment! Co-enrolling features cannot use most
of the traditional APIs, like
`ExperimentAPI.get{Experiment,Rollout,Enrollment}MetaData` or
`ExperimentFeature.getAllVariables` / `ExperimentFeature.getVariable`.
Instead, these features must use new co-enrollment aware APIs:
- `ExperimentAPI.getAllEnrollmentMetadata`, which returns the metadata
for all active enrollments for a given feature;
- `ExperimentAPI.getAllEnrollments`, which returns the same metadata, as
well as the feature values for all active enrollments for a given
feature;
`ExperimentFeature.recordExposurEvent` will work for co-enrolling
features, but callers must always provide a slug when calling so that we
know what enrollment caused the exposure.
In that vein, `ExperimentAPI.get{Experiment,Rollout,Enrollment}MetaData`
can still be called with the slug for a feature for a co-enrolling
experiment.
Differential Revision: https://phabricator.services.mozilla.com/D245986
We don't need so many wrappers and so on. Similarly we don't need
.menu-right, we can use ::after to draw the arrow.
This makes reasoning about menus a lot easier.
Differential Revision: https://phabricator.services.mozilla.com/D245000
From: Sarah Jamie Lewis <sarah@openprivacy.ca>
When the parental controls service is disabled in a build, the DoH
settings now display the correct stauts when Increased or Max Protection
is enabled.
Previously, selecting either of these options would cause DoH to be
enabled, but the "Status" and "Provider" fields would not be properly
populated, due to a check on the gParentalControlsService causing an
error.
This check is now identical to the same check in DownloadIntegration.sys.mjs
Apply 1 suggestion(s) to 1 file(s)
Co-authored-by: ma1 <giorgio@maone.net>
Differential Revision: https://phabricator.services.mozilla.com/D244850
Please see the bug for the motivation.
This adds a new `SuggestFeature.primaryUserControlledPreference` getter that
returns the feature-specific pref that lets the user toggle on/off the feature.
That way we can add `QuickSuggest.clearDismissedSuggestions()`, which goes
through each feature and clears that pref, and `canClearDismissedSuggestions()`,
which goes through and checks whether there are any prefs that can be cleared.
I also added a couple of notification topics for dismissals that the settings UI
uses to update the disabled state of its Restore button.
All of this will let us more easily move to the Suggest Rust component's
dismissal API too, which we should sooner or later.
Depends on D244865
Differential Revision: https://phabricator.services.mozilla.com/D244866
Without this, in my testing with the previous patch, the scroll alignment on
the initial load of the settings page is incorrect, with the top of the
section being cut off. As this is the situation we care about (first load after
a browser update), fixing it seemed important.
I spent some time trying to work out why layout is changing - presumably
items above the "Browser Layout" section are either appearing or disappearing
in a way that races with the scroll. I could never reproduce on any loads other
than the first one. But then I realized the code here was overly complex and
that it would probably be nicer for items to appear in the middle of the view
rather than the top anyway. Yes, this means that sometimes the relevant header
is _still_ not _exactly_ in the middle, but that seems much less important.
Differential Revision: https://phabricator.services.mozilla.com/D241628
