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
This does a few things:
* Unify the view implementations of rich suggestions, Firefox Suggest sponsored
results, and best match. I did this by using the best match implementation
and extending it to rich suggestions and Suggest sponsored.
* Use the unified implementation for Pocket suggestions too.
* Add a bottom-text concept since Pocket suggestions shown as top picks need to
show both a description and some text below it. (The actual bottom text per
result is added in D182632 since I didn't want to make this patch bigger than
necessary)
I have a couple motivations for these changes:
* I'm implementing Pocket suggestions, which need to show some text below the
suggestion title as well as the URL. I was going to just use the Firefox
Suggest sponsored approach, where the action text is wrapped below the title,
but that doesn't work because it can't show both the wrapped action text and
the URL.
* IMO we should use rich suggestions as the basis for all rows going forward,
i.e., unify the different row implementations around rich suggestions.
The reason I chose the best match implementation instead of the rich suggestions
implementation is because the grid-based approach of rich suggestions doesn't
work well when the URL also needs to be shown. The URL should be
baseline-aligned with the row title, which isn't easy to do when the URL is
outside the grid. The rich suggestions implementation also doesn't wrap the URL.
Other details:
* The `rich-suggestion=no-icon` attribute value is only used for styling, so we
can replace it with `@supports -moz-bool-pref()`. That lets us make the
`rich-suggestion` attribute a simple boolean.
* I kept the `isBestMatch` property for results since
`searchEngagementTelemetryGroup()` uses it to return "top_pick", and the view
also uses it to create the "Top pick" row/group label. It still has semantic
meaning so I think that's OK. It's no longer used by the view to create
different DOM or styling.
* Move `isRichSuggestion` from the payload to the result itself, since it's no
longer used for only one type of result. It's like `isBestMatch`, which is
also on the result.
* Add `richSuggestionIconSize` to the result too. The best match icon size
is 52. The Pocket best match icon size is 24 (but will have added padding and
a background color to make it appear 52px). IMO this is better than adding
rules for each type of suggestion to the CSS. It's cleaner and also indicates
what the "standard" icon sizes are.
Depends on D182580
Differential Revision: https://phabricator.services.mozilla.com/D182537
Each suggestion has "low" and "high confidence" keywords. When a high confidence
keyword is matched, the suggestion should be shown as a top pick, and otherwise
it should be shown as a normal Suggest result. High confidence keywords must be
matched in full, but low confidence keywords can be matched with prefixes
starting at the first word.
The low confidence matching behavior is the same as addon suggestions, so I
factored out that function into a new helper defined on `SuggestionsMap`.
I added a `full_keyword` property to the suggestions. It's not used yet but
we'll use it when we implement the final UI, which needs to show the full
keyword.
Differential Revision: https://phabricator.services.mozilla.com/D182580
