This integrates Rust exposure suggestions with desktop. Exposure suggestions are
a part of the replacement for the existing potential exposures feature
(bug 1881875). When we want to test potential exposures in the future, we can
add new exposure suggestions to remote settings and tell the Rust component to
ingest them and return them in queries. When the Rust component returns an
exposure suggestion, desktop will record it in exposure telemetry. (The other
part of the replacement is keyword exposure telemetry in bug 1915507 D220501).
More details about the design of exposure suggestions here:
* Bug 1893086
* https://github.com/mozilla/application-services/pull/6343
The way desktop tells the Rust component about different types of exposure
suggestions is through the new "provider constraints" feature. `ingest()` and
`query()` can take a `SuggestionProviderConstraints` object that changes what's
ingested and queried. Therefore, we need to re-ingest exposure suggestions when
the provider constraints change. Right now, exposure suggestions are the only
kind of suggestions that use provider constraints.
Depends on D220359
Differential Revision: https://phabricator.services.mozilla.com/D220359
Please see the bug for details.
This makes some changes to search strings and URLs in the tests that might look
unnecessary. They're due to switching to the QuickSuggestTestUtils helpers in
the head files instead of hardcoding the suggestions data. It's possible to
force the helpers to use the existing search strings and URLs that are used in
these tests, but it's good to be consistent with other tests that use these
helpers because it makes everything easier to understand.
Depends on D220352
Differential Revision: https://phabricator.services.mozilla.com/D219943
The error was:
ERROR: Unknown target name: "appendix b: using the webextensions api directly".
This is out of date documentation as we no longer support webextensions for dynamic result types.
Differential Revision: https://phabricator.services.mozilla.com/D220532
This keeps track of the enabled suggestion types that have been ingested while
the app is running. I call those types "fresh". In the code, they're stored in
the `#ingestedSuggestionTypes` set. Types that have not been ingested and types
that are disabled are called "stale". When a feature is updated, we update the
staleness bookkeeping in `#ingestedSuggestionTypes` and ingest only enabled
stale types.
This is similar to how each feature has an `#isEnabled` property. It's our
cached value of the last-known state that we can compare to the current state.
Depends on D219943
Differential Revision: https://phabricator.services.mozilla.com/D220352
Please see the bug for details.
This makes some changes to search strings and URLs in the tests that might look
unnecessary. They're due to switching to the QuickSuggestTestUtils helpers in
the head files instead of hardcoding the suggestions data. It's possible to
force the helpers to use the existing search strings and URLs that are used in
these tests, but it's good to be consistent with other tests that use these
helpers because it makes everything easier to understand.
Depends on D219942
Differential Revision: https://phabricator.services.mozilla.com/D219943
This replaces `UrlbarResult.exposureResultType` and `exposureResultHidden` with
a single simple value called `exposureTelemetry`. Please see the bug for the
rationale.
Other changes:
* For convenience, make `UrlbarPrefs.get("exposureResults")` return a `Set` so
consumers don't have to parse the string value.
* Simplify handling of result properties in `check_results()` (xpcshell tests)
* Add more tasks/checks to test_exposure.js
Depends on D219939
Differential Revision: https://phabricator.services.mozilla.com/D219942
As part of bug 1914535, I'd like to move some Suggest xpcshell test helpers from
head.js to QuickSuggestTestUtils so that other tests outside the quicksuggest
directory can use them and also so that Suggest helpers are more centralized.
This doesn't make any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D219939
This switches from the deprecated/removed jsdoc/newline-after-description rule to using the replacement jsdoc/tag-lines rule.
Differential Revision: https://phabricator.services.mozilla.com/D219512
This switches from the deprecated/removed jsdoc/newline-after-description rule to using the replacement jsdoc/tag-lines rule.
Differential Revision: https://phabricator.services.mozilla.com/D219512
The Persistent Search Terms feature is enabled until late beta, hence
why the test is failing late beta and beyond.
I might've integrated the PST with scotchBonnet.enableOverride but
it seems like there's some open threads right now (e.g. should the
feature work on non-default search engines, background colour choice)
that I'm hesistant on making it a blocker to Scotch Bonnet.
Differential Revision: https://phabricator.services.mozilla.com/D219640
**Description**
- Add autofill functionality to UrlbarProvider Restrict Keywords.
**Acceptance Criteria**
- There are 3 restrict keywords `@history`, `@bookmarks`, and `@tabs`
- When the user types @ followed by the beginning of the search keyword: `@h`, `@hi`, `@his`, `@hist` etc. the user should be able to autofill the rest of the search by pressing tab
- The autofill should highlight the typed letters from the user, and show the entire keyword following what the user typed. For example:
- If the user typed `@hist` , autofill should highlight what the user typed and show the rest of the keyword `@history`:
**Example steps to test `@history` :**
- set `browser.urlbar.searchRestrictKeywords.featureGate` to true
- type out the full keyword and space `@history` , address bar should show results panel with history results
- type `@h` and press right arrow, shows results panel with history results
- type `@h` and press enter, shows results panel with history results
- type `@h` and press tab, does not show panel but selects the history restrict result. When the user starts typing, it will search their history and show results panel with history results
Differential Revision: https://phabricator.services.mozilla.com/D218742
The main thing this does is add a task to the Fakespot engagement telemetry test
that triggers both a Fakespot and history result and then clicks the history
result. I want to make sure the Fakespot engagement event isn't incorrectly
recorded. (I thought it might be but it's not.)
This also has a bunch of changes from http to https. Lint made me change the
URLs in the Fakespot test to https, which was a problem for the AMP result since
`QuickSuggestTestUtils.ampRemoteSettings()` uses http URLs. So I went ahead and
updated that function plus the other ones and all the places that are affected.
Depends on D217780
Differential Revision: https://phabricator.services.mozilla.com/D217887
