Density changes called directly into the urlbar input to update the
breakout. But when customizing the urlbar shouldn't break out.
That means that this code is mostly for when density is changed via
another window, or direct pref changes I guess.
Differential Revision: https://phabricator.services.mozilla.com/D236539
This makes a few changes:
Make sure we always set `result.payload.isSponsored` and base it on
`SuggestProvider.isSuggestionSponsored()` so that it's really clear. With that
change, we don't need to set `suggestion.is_sponsored` anymore. (I'm trying to
stop modifying suggestion objects so much because it's hard to follow.)
Don't call `feature.makeResult()` if the feature is disabled. I'm kind of
surprised we don't do this already, but it's always worked out in the end due to
a few reasons: (1) Some `feature.makeResult()` implementations return null if
their prefs are disabled (effectively duplicating their `shouldEnable` logic),
(2) we don't query the Rust component for disabled suggestions, and (3)
`#canAddSuggestion()` returns null if sponsored/nonsponsored suggestions are
disabled.
Replace `#canAddSuggestion()` with `#canAddResult()`. The logic can be
simplified and is easier to follow if we always deal with results instead of
suggestions. Examples: (1) We can check `result.payload.isSponsored` instead of
having to also set and check `suggestion.is_sponsored`. (2) When checking for
blocked suggestions, we can check `result.payload.originalUrl` instead of
leaking `suggestion.rawUrl` from the Rust component.
Differential Revision: https://phabricator.services.mozilla.com/D235389
This patch makes it unnecessary for most features to have to override
`shouldEnable`. Instead, the Suggest framework will check `enablingPreferences`
plus a new property called `additionalEnablingPredicate`. Summary:
* Include Nimbus variables in `enablingPreferences`
* Add a new property to `SuggestFeature` called `additionalEnablingPredicate`
* Make `shouldEnable` call `enablingPreferences` and
`additionalEnablingPredicate`
* Remove `shouldEnable` implementations on most features
Differential Revision: https://phabricator.services.mozilla.com/D235251
I don't think we have any tests specifically for Merino suggestions that don't
correspond to Suggest features, i.e., suggestions with a Merino provider that is
technically unrecognized by Firefox. Dynamic Wikipedia suggestions and
navigational suggestions (a.k.a. top sites) are two examples. So I added tasks
for both sponsored and nonsponsored suggestions to make sure they're disabled
when the relevant pref is disabled, in addition to testing this bug itself.
Differential Revision: https://phabricator.services.mozilla.com/D234787
This builds on D233752 and submits a deletion-request ping when either AMP
suggestions or the entire Suggest feature becomes disabled.
`context_id` is sent in this new ping just like the `quick-suggest` ping.
Depends on D233752
Differential Revision: https://phabricator.services.mozilla.com/D233983
With D234449 fixed, we can change `SuggestProvider.rustSuggestionTypes` (plural)
to `rustSuggestionType` (singular). We can remove `isRustSuggestionTypeEnabled`
too because it's assumed that if the feature itself is enabled then its Rust
suggestions are too. I don't expect we'll ever need to break that assumption,
but if we do, we can just add back `isRustSuggestionTypeEnabled` at that time.
Depends on D234449
Differential Revision: https://phabricator.services.mozilla.com/D234450
This makes two major changes:
Split `AdmWikipedia` into `AmpSuggestions` and `OfflineWikipediaSuggestions`. I
included "offline" in the name because Merino also serves Wikipedia suggestions,
but they're the so-called "dynamic Wikipedia" suggestions served from
Elasticsearch, and they have never been managed by a
`BaseFeature`/`SuggestFeature` in Firefox.
Send the `quick-suggest` ping only for AMP suggestions, in `AmpSuggestions`.
Stop sending it for offline Wikipedia suggestions. @bholley and I discussed this
on the data-review@mozilla.com list after I emailed it for the senstive data
review in D233752 [1]. We only use the ping for AMP suggestions, and Wikipedia
telemetry should follow the usual data opt-out. @nanj agreed the ping isn't
necessary for Wikipedia.
[1] https://groups.google.com/a/mozilla.com/g/data-review/c/BC2JKaXA7nA
Depends on D234440
Differential Revision: https://phabricator.services.mozilla.com/D234449
This renames `browser_telemetry_other.js` to `browser_telemetry_environment.js`
since it only tests `TelemetryEnvironment` now.
A few tasks do the same thing (with different pref values), so I also factored
that out into a `doToggleTest()` helper.
Also, there are some chunks in this test that don't actually do anything
anymore, so I've removed them. Those chunks were modified in bug 1921748 due to
removal of some legacy telemetry events, and we should have removed them then
but it was my fault for not realizing that.
Depends on D234257
Differential Revision: https://phabricator.services.mozilla.com/D234258
The Suggest tests that use `doTelemetryTest()` only test the `quick-suggest`
ping now due to the fact we removed most Suggest legacy telemetry recently. To
make that clearer, this revision renames those tests and the helper functions.
It also simplifies the helper params since they don't need to test anything
other than the ping.
Depends on D233980
Differential Revision: https://phabricator.services.mozilla.com/D234257
Previously, URLs ending with a `?` were treated as search strings and redirected
the search to the default search engine.
This patch ensures the URL is visited instead of doing a search to the default
search engine. The search restrict token `?` is now ignored when it appears at
the end of the search string.
Differential Revision: https://phabricator.services.mozilla.com/D233311
