This patch adds telemetry for when the user sees or interacts with restrict keyword results.
Following is an overview of the interactions that will trigger the telemetry to be recorded:
When the user types `@` and selects one of the restrict results, the scalar telemetry will be recorded:
- `urlbar.picked.restrict_keyword_tabs`
- `urlbar.picked.restrict_keyword_bookmarks`
- `urlbar.picked.restrict_keyword_history`
- `urlbar.picked.restrict_keyword_actions`
For example, we can select the tabs result in multiple ways for the telemetry to be recorded:
- type`@` and click on tabs result
- type`@` and arrow down to tabs result and press enter
- type partial keyword `@t` and press enter to autofill
- type partial keyword `@t` and press tab and then enter
When the user types `@` and **does not** select one of the restrict results, the glean abandonment will be recorded:
```
groups:
"general,general,general,general,general,general,restrict_keyword,restrict_keyword,restrict_keyword,restrict_keyword",
results:
"search_engine,search_engine,search_engine,search_engine,search_engine,search_engine,restrict_keyword_bookmarks,restrict_keyword_tabs,restrict_keyword_history,restrict_keyword_actions",
```
When the user types `@` and **does** select one of the restrict results, the glean engagement will be recorded:
```
groups:
"general,general,general,general,general,general,restrict_keyword,restrict_keyword,restrict_keyword,restrict_keyword",
results:
"search_engine,search_engine,search_engine,search_engine,search_engine,search_engine,restrict_keyword_bookmarks,restrict_keyword_tabs,restrict_keyword_history,restrict_keyword_actions",
selected_result: `restrict_keyword_${category}`,
```
For the `selected_result` in engagement telemetry, the `category` variable will be `tabs, bookmarks, history, or actions`.
Differential Revision: https://phabricator.services.mozilla.com/D222355
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
**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
This patch includes:
- A new UrlbarProviderRestrictKeywords class
- Showing localized Search with Bookmarks, Search with History, Search with Tabs results after the user types @
- Add search restrict keywords to preferences UI Search Shortcuts table
- Hiding search restrict keyword behind browser.urlbar.searchRestrictKeywords.featureGate pref
Differential Revision: https://phabricator.services.mozilla.com/D213697
Please see the bug for context. This changes how ingest works. Right now we
ingest all "default" suggestion types at once. This patch causes a suggestion
type to be ingested only when it's enabled.
Before this patch, there are two times ingest happens, on startup and when the
ingest timer fires.
With this patch, there are now a few times ingest happens:
* On startup (as before). `SuggestBackendRust` will ingest all registered and
enabled suggestion types.
* When the ingest timer fires (as before). Similar to startup, all registered
and enabled types will be ingested.
* When a suggestion type becomes enabled. I added this functionality to
`BaseFeature.update()` so that each feature gets this behavior automatically.
It's worth saying more about the startup case. On startup, all `BaseFeature`s'
initializations race each other. `SuggestBackendRust` is itself a `BaseFeature`,
so there's no guarantee it will be initialized before other `BaseFeature`s that
implement Rust suggestions. If any `BaseFeature`s are initialized before
`SuggestBackendRust`, they'll try to ingest but nothing will happen because
`SuggestBackendRust` won't be initialized yet. Once `SuggestBackendRust` is
initialized, it will ingest suggestions for all registered `BaseFeature`s that
already tried and failed to ingest. And after `SuggestBackendRust` initializes,
any `BaseFeature`s that are initialized later will be able to successfully
ingest.
Differential Revision: https://phabricator.services.mozilla.com/D216488
When the address bar adds a non typed protocol, don't show the urifixup added
protocol to the user, as https-first may upgrade it, and the whole experience
could be confusing for the user.
Differential Revision: https://phabricator.services.mozilla.com/D213443
The InputHistory (adaptive) provider is not properly reporting the open tab
userContextId, thus the Muxer is unable to dedupe results properly.
This cleans up the query a little bit avoiding numeric indices and fields that
are unused later.
Differential Revision: https://phabricator.services.mozilla.com/D203012
There are two types of config in Rust Suggest: global and per-provider. Right
now global contains `show_less_frequently_cap`, and the only provider config is
for weather, which contains `min_keyword_length`. This patch uses both of them.
It makes sense to me to fetch config as part of the ingest process, so that's
what I've done. I'm not sure when else would be a good time. It's async so it's
not too convenient to do it on demand.
In RS records and attachement JSON, we use snake_case, but Rust converts it to
camelCase (actually UniFFI does, I think). That means the JS backend will use
snake_case for all config, but the Rust backend will use camelCase. I wrote a
helper for converting snake to camel so we can always just use camel.
Depends on D200755
Differential Revision: https://phabricator.services.mozilla.com/D201023
This patch requires https://github.com/mozilla/application-services/pull/6089,
which hasn't been vendored yet, so it will be hard to test unless you locally
vendor. I've done that and verified that weather tests still pass.
Weather suggestions in Rust work like this: Rust stores the weather keywords in
the `keywords` table, and when the query matches a keyword, it returns a dummy
`Weather` suggestion that only contains a score. That means weather suggestions
are handled nearly like every other type of suggestion, except when Firefox
receives a weather suggestion from Rust, it must replace it with the actual
suggestion from Merino.
We also need to continue to support weather keywords defined in Nimbus. For
that, this patch continues to use `UrlbarProviderWeather` because I don't want
to add a special case to `UrlbarProviderQuickSuggest` just for this one type of
suggestion. When we stop experimenting with weather, we can remove that
provider.
I moved all the common code from `UrlbarProviderWeather` to `Weather` so both
providers can use it.
Some of the tests check `minKeywordLength` and can't use Rust yet. I'll handle
that in bug 1878444.
Depends on D200105
Differential Revision: https://phabricator.services.mozilla.com/D200755
Fixes code to properly run tests with the feature enabled.
Fixes code not considering payload.userContextId is set to -1 for private
windows.
Fixes a bug in the _openTabs Map where multiple open tabs to the same url are
not properly counted.
Differential Revision: https://phabricator.services.mozilla.com/D200036
ext-urlbar.js is unused but will be removed in a separate
patch to avoid test failures in condprof tests. Condprof tests may use
an outdated profile directory that still references ext-urlbar.js in
startupcache files, which triggers a test-only test failure in
mozilla::net::CheckForBrokenChromeURL.
Differential Revision: https://phabricator.services.mozilla.com/D199769
This fixes the two `#addExposure()` calls in `UrlbarView.#updateResults()` so
that hidden exposures are properly counted. Right now we overcount them because
we record them in cases where the result would not have been shown anyway.
The new test tries to cover all possible `UrlbarView.#updateResults()` paths:
* When the view is full and a new result can't replace any of the old rows, the
new result is appended and hidden. If the query is then canceled, the new row
will never be shown
* When the vew isn't full, a new row can be appended and visible immediately
* When a new row replaces an old row, it can be visible immediately
Differential Revision: https://phabricator.services.mozilla.com/D199176
This is a hack for the experiment and likely not ideal for screen readers, but better than what we have. I'm reaching out to a11y folks to figure out the right long-term solution here. I'll make an effort to get that ready for the experiment too, but would like to get this landed as a backup.
Differential Revision: https://phabricator.services.mozilla.com/D194501
The new Rust implementation of Suggest stores icons for some suggestion types in
its Sqlite database, and it returns these icons to consumers as byte arrays. To
show these icons in the view quickly and without any overhead, we can create
`Blob` URLs from the arrays. Blob URLs need to be revoked when we're done with
them to avoid leaking the backing data.
This patch implements some simple lifetime management of blob URLs in the view.
The first time the view shows a result, it creates a blob URL for the result's
icon. The view caches the URL while it remains open, so as the user continues to
type and possibly match the same result many times, the view will use the same
blob URL each time. When the view closes, it revokes the URL. This seems like a
reasonable, natural lifetime for these URLs, and the implementation is simple.
Depends on D189452
Differential Revision: https://phabricator.services.mozilla.com/D189615
