This adds a new Suggest backend for ML-based suggestions called
`SuggestBackendMl`. Before, with the JS and Rust backends, only one backend was
enabled at a time, but both the ML and Rust backends can be enabled at the same
time since we will want to serve suggestions from both for the foreseeable
future. Features can support ML suggestions by implementing the new
`BaseFeature.mlIntent` getter and handling ML suggestions in `makeResult()`.
Each feature can decide whether it supports ML suggestions and whether they
should be preferred over Rust suggestions.
I've updated the Yelp feature to hook into this, since Yelp suggestions are
supported by the ML model that Chidam is working on. If ML is enabled, then the
feature will only serve ML suggestions. I'm not sure if that's what we want long
term, but for now that will make it clear to people which backend is being used
while we develop this feature.
The `quickSuggestMlEnabled` variable/pref determines whether the ML backend is
enabled. The `yelpMlEnabled` variable/pref determines whether Yelp ML
suggestions are enabled. We can create similar variable/prefs for each feature
that supports ML suggestions so that they can be toggled independently of each
other.
Other changes:
Move the `is_sponsored` logic out of the Rust backend and into the provider.
Otherwise it would need to be duplicated in the ML backend too.
Depends on D224523
Differential Revision: https://phabricator.services.mozilla.com/D226736
This adds support for city-based weather suggestions from Rust, i.e., queries
that contain city and region names.
When Rust detects a weather query with a city, it sets three suggestion
properties: `city`, `region`, and `country`. All three properties will be set
because the Rust component knows which cities are in which regions and
countries, and it will only set the properties if it detects a city name. If a
name matches multiple cities and the query doesn't contain a region, Rust will
return multiple suggestions, one suggestion per city-region, and the suggestions
will be ordered by population size, largest to smallest.
Rust uses data from GeoNames to detect locations. We store GeoNames data in
remote settings and ingest it into the Rust DB, just like we do for suggestions
and keywords. This patch uses some mock GeoNames data in the test.
More info on the Rust part of this in the PR:
https://github.com/mozilla/application-services/pull/6406
For the Merino part, Merino now supports a few extra params for weather
suggestions: city, region, and country. So when the Rust component returns a
weather suggestion with those properties set, we can pass them to Merino to get
a weather suggestion for that location.
This patch adds a new `BaseFeature` method called `filterSuggestions()`. The
important thing about this method is that it's passed all the feature's
suggestions that were matched in the query. The feature can use this info to
determine which suggestion(s) to show. Right now, `Weather` uses it to discard
all weather suggestions except the first one, which means it will show the
suggestion with the largest city population (if the first suggestion has a
city). In the future, I'd like to explore better options like picking the
suggestion whose city name best matches the user's location.
Depends on D226215
Differential Revision: https://phabricator.services.mozilla.com/D226584
This replaces `MerinoTestUtils.WEATHER_RS_DATA` with
`QuickSuggestTestUtils.weatherRecord()`. Weather records now have an attachment
instead of storing their keywords inline. I also removed
`MerinoTestUtils.WEATHER_KEYWORD` because I think it's fine to use "weather"
directly everywhere, and that's simpler.
Some tests also need to be updated for the slight changes in keyword matching,
and some tasks don't make sense anymore.
Depends on D226214
Differential Revision: https://phabricator.services.mozilla.com/D226215
* Fix various z-index/paint order issues by making the urlbar a popover - which moves the open
urlbar to the top layer, outside the toolbox
* Adjust the urlbar position when the autohide menubar shows and hides
* Temporarily disable the browser_urlbar_keyed_search.js which needs revisiting to measure reflows under regular, non-test-specific conditions
Combines work from nsharpley and sfoster on top of emilio's original popover patch
Differential Revision: https://phabricator.services.mozilla.com/D224201
* Fix various z-index/paint order issues by making the urlbar a popover - which moves the open
urlbar to the top layer, outside the toolbox
* Adjust the urlbar position when the autohide menubar shows and hides
Combines work from nsharpley and sfoster on top of emilio's original popover patch
Differential Revision: https://phabricator.services.mozilla.com/D224201
- `urlbar.searchmode.typed`: suffixed with "keyword" for restrict keyword entries and "symbol" for symbol entries.
- `urlbar.searchmode.keywordoffer`: suffixed with "keyword" for restrict keyword entries via keywordoffer.
- Example: History search mode scalar key is `history_keyword` for restrict keyword and `history_symbol` for symbol.
Differential Revision: https://phabricator.services.mozilla.com/D223210
The main goal is to simplify the logic in setURI, and create a more easier to understand flow of operations.
It involves making Persisted Search more contained, offload some responsibilities to UrlbarSearchTermsPersistence, and store fewer state variables than the patch that was first reviewed. I also simplified code in UrlbarSearchTermsPersistence.
**How Search Terms Persist:**
**Step 1**
When the page first appears, set state for search terms persistence. First load doesn't necessarily mean no tab switch or same page load, as a user could load a browser in the background tab. In that latter case, the first "view" may occur on a tab switch and the state won't exist because `setURI` will never have been called with that browser object being selected.
Once the state has been set, the only property that could be updated is `shouldPersist`. Otherwise, don't update the state object unless a full new page load occurs.
**Step 2**
Call `shouldPersist`. This has all the logic for when search terms should persist and gets called anytime `setURI` is called.
The conditions in which we shouldn't persist:
- There's no reason to show search terms:
- The persist state is missing.
- There are no search terms extracted from the URL.
- We need to temporarily hide the search terms, such as by handleRevert
- `hideSearchTerms` is provided to setURI
- There is an user typed value and it differs from the search terms
- A single page application moved to a secondary page
- After the initial page load, there's the search mode (or lack of search mode) differs from the persist engine.
**Step 3**
Determine if we need to update `this.window.gBrowser.userTypedValue`. If we're going to persist, set `userTypedValue` to the search terms, which will keep the search mode and non-search mode state consistent. This'll also enable the ability to reuse existing logic that determines how to set `value`.
On same page loads, when switching from persist to non-persist, and search term equals the userTypedValue, then `null` the userTypedValue so that the URL shows.
**Step 4**
In the area of setURI which has logic for search mode, if we persist, ensure the search mode (or lack of search mode) is consistent with the engine. If it is, do nothing. If it isn't, either nullify the search mode or enter search mode.
Differential Revision: https://phabricator.services.mozilla.com/D224520
- `urlbar.searchmode.typed`: suffixed with "keyword" for restrict keyword entries and "symbol" for symbol entries.
- `urlbar.searchmode.keywordoffer`: suffixed with "keyword" for restrict keyword entries via keywordoffer.
- Example: History search mode scalar key is `history_keyword` for restrict keyword and `history_symbol` for symbol.
Differential Revision: https://phabricator.services.mozilla.com/D223210
- `urlbar.searchmode.typed`: suffixed with "keyword" for restrict keyword entries and "symbol" for symbol entries.
- `urlbar.searchmode.keywordoffer`: suffixed with "keyword" for restrict keyword entries via keywordoffer.
- Example: History search mode scalar key is `history_keyword` for restrict keyword and `history_symbol` for symbol.
Differential Revision: https://phabricator.services.mozilla.com/D223210
This patch adds the keywords to the result title for TokenAliasEngine and
RestrictKeyword results. The TokenAliasEngine results may have more than one
keyword if the user has set a custom keyword for that engine. This can help
remind the user what keywords are available as they are typing or if they
have forgotten a keyword, they can type `@` to quickly see the list of keywords
to search with.
The result title looks like this:
For Engines:
@[keywords] - Search with [Engine]
For Restrict Keywords:
@[keyword] - Search [Restrict]
Differential Revision: https://phabricator.services.mozilla.com/D224017
