Keep using the static position as we did before. As long as we don't
have anchor positioning this seems better than whack-a-mole-ing every
possible urlbar position change.
In order to make the fullscreen animation work, make our position
computation ignore transforms, which is how anchor positioning would
behave anyways.
Differential Revision: https://phabricator.services.mozilla.com/D227758
This was a pre-existing issue that was only papered by chance.
this._toolbar is set before the early return for readonly urlbars, but
the ResizeObserver is only set up after it.
Be more explicit about when we allow breaking out of the container (and
effectively do it only for non-readonly urlbars).
Differential Revision: https://phabricator.services.mozilla.com/D227760
This was accidentally disabled in bug 1920531 with the re-organisation of how eslint-plugin-mozilla worked.
The rule needs to be (re)enabled after eslint-config-prettier is applied, as eslint-config-prettier turns it off by default.
Differential Revision: https://phabricator.services.mozilla.com/D227621
This adds some logic on top of D226858 that computes the distance between the
client's geolocation coordinates and weather suggestions' coordinates. It works
really well. We still fall back to comparing the region and country if the
coordinates aren't present in the geolocation, but in practice, I'm not sure
Merino will ever return a geolocation without coordinates.
Also, I realized that we don't need to sort the suggestions to find the one with
the best region/country. We only need to do one loop through them.
Depends on D227271
Differential Revision: https://phabricator.services.mozilla.com/D227301
The static position of these boxes is not great to depend upon, see:
https://github.com/w3c/csswg-drafts/issues/9939
Right now, we are relying on the static pos to be properly set which is
going to go away, eventually, and it is bogus, because it doesn't update
if e.g. only transform changes.
Use getBoxQuads to get the content box bounds properly. Also, make
breakout position: absolute explicitly, to prevent confusion.
Differential Revision: https://phabricator.services.mozilla.com/D226932
There were trivial failures in some urlbar tests due to the weather suggestions
changes that are the reason for this vendor, plus some ingest metrics changes in
this revision:
7e71b6a672
Differential Revision: https://phabricator.services.mozilla.com/D227271
The static position of these boxes is not great to depend upon, see:
https://github.com/w3c/csswg-drafts/issues/9939
Right now, we are relying on the static pos to be properly set which is
going to go away, eventually, and it is bogus, because it doesn't update
if e.g. only transform changes.
Use getBoxQuads to get the content box bounds properly. Also, make
breakout position: absolute explicitly, to prevent confusion.
Differential Revision: https://phabricator.services.mozilla.com/D226932
It's not easy to write a test for this since it's hard to test icons. I've
tested it manually with ML enabled and disabled. I'll look into adding icon
tests.
Differential Revision: https://phabricator.services.mozilla.com/D226874
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
