This adds a `quickSuggestScoreMap` Nimbus variable that lets experiments
override suggestion scores. It maps from telemetry types to score values. For
example:
```
"quickSuggestScoreMap": {
"amo": 0.25,
"adm_sponsored": 0.3
}
```
In this example, addon suggestions will always have a score of 0.25, and
sponsored suggestions will always have a score of 0.3. Of course, different
branches within an experiment and different experiments can set different
scores.
While working on this, I saw we have a bug when we try to look up the
`BaseFeature` for a result. To do the lookup, we look up the result's
`telemetryType` in `FEATURE_NAMES_BY_TELEMETRY_TYPE`. That's a problem for `adm`
suggestions because the `telemetryType` will be either `adm_sponsored` or
`adm_nonsponsored`, but neither of those is present in
`FEATURE_NAMES_BY_TELEMETRY_TYPE` -- only `adm` is.
To fix it, I added back the `provider` property to result payloads that I
previously removed, and I added `BaseFeature.merinoProvider` so each feature can
specify its Merino provider. Then, `QuickSuggest` can build a map from Merino
provider names to features, allowing us to look up features without needing to
hardcode something like `FEATURE_NAMES_BY_TELEMETRY_TYPE` or
`FEATURE_NAMES_BY_MERINO_PROVIDER`.
Since I added back the `provider` property, I had to update a lot of tests. (As
a follow up, it would be nice to centralize the creation of expected result
objects in the test helper.)
I also added `BaseFeature.getSuggestionTelemetryType()` to help implement the
score map and to better formalize the idea that telemetry types are an important
property that all quick suggest results should include.
Differential Revision: https://phabricator.services.mozilla.com/D181709
This goes through the previous changes in the dependencies of bug 877389, and does two things:
1) Remove instances of \n
2) Change reporting of exceptions so that they are passed as separate arguments. This should result
in an improved display of the exception in the browser console, should it occur.
Differential Revision: https://phabricator.services.mozilla.com/D180843
This implements most parts of Pocket suggestions. They don't need any special UI
or a dynamic result type because they're only shown as the usual best match rows
or non-best match rows.
Still to do:
* Implement the "Show less frequently" behavior once we decide what the keywords
will be and how that will work.
* Implement the bottom "Mozilla Pocket" text inside the suggestion row once it's
finalized. We can use the same technique we use to show the "Sponsored" bottom
text for adM suggestions.
Other changes this makes:
* Replace the `type=bestmatch` attribute with an `bestmatch` attribute. That
lets best-match rows have a `type` too, in this case `"pocket"` (actually
either `"rs_pocket"` or `"merino_pocket"`, since I'm using the telemetry
result type).
* Improve how UrlbarProviderQuickSuggest delegates to individual features when
getting result commands, view updates, handling commands, etc., so that we
don't need to add new `case` statements for each new type of suggestion.
Differential Revision: https://phabricator.services.mozilla.com/D180059
This implements the new required matching behavior, which isn't based on min
keyword length anymore. This is how it works:
* Use the full keywords in remote settings to generate keywords that contain the
first word plus each possible substring after the first word. For example if a
full keyword is "video download", then generate these keywords: "video",
"video ", "video d", "video do", etc. If a full keyword is only one word, then
use it as is. The keywords never change even when the user clicks "Show less
frequently". This is implemented in `onRemoteSettingsSync()`, and I modified
`SuggestionsMap.add()` to make it easy to generate new keywords from the
strings in `suggestion.keywords`.
* Keep track of the number of times the user clicked "Show less frequently" in
`showLessFrequentlyCount`.
* When a suggestion is fetched from the suggestions map, filter it out if the
search string isn't long enough given the `showLessFrequentlyCount`. This is
done in `makeResult()`.
Other changes:
* I made some of the private properties in `AddonSuggestions` public so that the
xpcshell test can easily use them. I think it's OK for them to be public.
* Added `show_less_frequently_cap` to the RS config object so that we can
specify a cap in RS as well as Nimbus.
* mv'ed test_quicksuggest_addResults.js to test_suggestionsMap.js, since I
modified this file. I should have done that back when I replaced `addResults()`
with `SuggestionsMap`.
* Fixed a bug in `SuggestionsMap.add()` where the same suggestion could be added
multiple times to the array stored in the map, if it had duplicate keywords.
Differential Revision: https://phabricator.services.mozilla.com/D179867
This increments the minimum keyword length when the user clicks the "Show less
frequently" command for the weather suggestion. It adds a pref to keep track of
the current min length. If the pref is zero, we use the min length in Nimbus or
remote settings.
There is a limit to the number of times "Show less frequently" can be clicked.
This patch calls it the cap. Once the cap is reached, the min length can't be
incremented any more and the command is not shown in the menu again. The cap can
be set in Nimbus and remote settings.
This patch also modifies UrlbarPrefs by making it possible to remove observers.
`Weather` needs to listen for changes to the `weather.minKeywordLength` pref,
and when the weather feature is disabled, it needs to stop listening.
Depends on D175827
Differential Revision: https://phabricator.services.mozilla.com/D177218
This change adds support for exposure based experiments by allowing
a Nimbus variable/pref to specify the urlbar provider that should
trigger an exposure event as well as a secondary boolean variable/pref
that controls the visibility of the exposed result. The exposure should
be registered when a result 'can be added' but may or may not be shown
based on the value of the `displayExposureProvider` variable.
* Add exposure event to metrics.yaml
* Add new Nimbus variable (`exposureProvider`) to specify the urlbar
providers that should trigger exposure events .
* Add new Nimbus variable (`displayExposureProvider`) that controls the visibility
of the provider results that matched the `exposureProvider` variable.
Differential Revision: https://phabricator.services.mozilla.com/D174209
This adds a bunch of scalars to record navigational suggestions telemetry as
discussed with data science and described in the spec. These scalars are
different from the other Suggest ones because we want to record how nav
suggestions interact with the heuristic result. Unlike the existing scalars, the
keys of these new scalars are the types of heuristics that were shown when a nav
suggestion was or wasn't shown. One of the scalars is updated every time a nav
suggestion is *not* shown, and of course for most users that will be the vast
majority of the time or all the time, so I put all these scalars behind a Nimbus
variable. We'll set the variable to true in the control and treatment branches
of the nav suggestions experiment.
This patch also makes sure nav suggestions are recorded properly in Glean, as
`navigational`. I noticed that dynamic Wikipedia results are currently recorded
as `suggest_non_sponsor`, so I also added a new `dynamic_wikipedia` Glean type
for them. They're also recorded as `urlbar.picked.quicksuggest` in the legacy
telemetry, so I also changed it so they're recorded as
`urlbar.picked.dynamic_wikipedia`.
Currently for dynamic Wikipedia, the non-sponsored scalars are also incremented,
and I discussed with data science whether they and the sponsored scalars should
be incremented for all the new Suggest suggestion types we now have. We agreed
that they should be reserved for the usual partner sponsored and expanded
Wikipedia suggestions, and they should not be used for these new Suggest types,
so this patch also makes that change, and it does not update the non-sponsored
scalars for nav suggestions either.
The other major change this makes is to add a new `subtype` property to quick
suggest result payloads. I think we need a clear, simple way to distinguish
between all these various Suggest suggestion types that doesn't depend on
examining different payload properties depending on the type.
Differential Revision: https://phabricator.services.mozilla.com/D171525
This reverts the changes from D168757 bug 1814795 related to remote settings. It
moves the weather keywords from the config in remote settings to a new Nimbus
variable called `weatherKeywords`. Bug 1817038 has more context.
It also adds another variable called `weatherKeywordsMinimumLength` that lets
the user type prefixes of the keywords instead of the full strings. This is
similar to how sponsored and Wikipedia suggestion keywords contain prefixes,
except here Firefox is computing the prefixes from the full keywords instead of
assuming that the prefixes are in the keyword data.
It also removes the `weather.zeroPrefix` pref added in D168757. Instead, the
weather suggestion is triggered on zero prefix if a Nimbus experiment isn't
active or if the experiment doesn't define `weatherKeywords`.
Finally, it makes one unrelated change: The user's search string can now contain
trailing spaces and still match a weather keyword. I don't think it makes sense
for the weather suggestion to be shown when you type "weather" but then it goes
away after you type a space.
Differential Revision: https://phabricator.services.mozilla.com/D169977
This is a test-only change. It introduces a new Urlbar pref to make the
existing 3000 ms timeout configurable.
That timeout is currently reached 8 times in the test. That means that
the test will take at least 3 x 8 = 24 seconds to run while basically
doing nothing, and makes the test prone to reach the deadline by which
the test is declared timed-out.
To avoid "Test timed out" errors, the test now reduces the fixed 3000 ms
timeout to 500 ms, so now we wait for 8x500 = 4 seconds instead of 24.
Differential Revision: https://phabricator.services.mozilla.com/D169846
MAX_OMNIBOX_RESULT_COUNT was introduced in bug 1267810 to increase compatibility with Chromium. It no longer serves this purpose as Chromium has since removed its limit of 6 extension-supplied results.
Differential Revision: https://phabricator.services.mozilla.com/D168891
MAX_OMNIBOX_RESULT_COUNT was introduced in bug 1267810 to increase compatibility with Chromium. It no longer serves this purpose as Chromium has since removed its limit of 6 extension-supplied results.
Differential Revision: https://phabricator.services.mozilla.com/D168891
This adds a new pref, `browser.urlbar.weather.zeroPrefix`. When true, weather
suggestions are shown on "zero prefix" like they are now, which means they're
shown when the user focuses the urlbar and before they type anything. When the
pref is false, the weather provider will show suggestions only if the search
string matches a keyword in a set of keywords managed by `QuickSuggest.weather`.
My plan is to store the keywords in the quick suggest config object in remote
settings. Nan suggested this too. Currently the config does not contain any
keywords, but this patch can be tested by setting the pref to false, running the
following in the browser console, and then typing "weather" in the urlbar:
```lang=js
ChromeUtils.importESModule("resource:///modules/QuickSuggest.sys.mjs")
.QuickSuggest.remoteSettings._test_setConfig({
weather_keywords: ["weather"],
});
```
Other changes:
* It's possible for a keyword to match both the weather suggestion and a quick
suggest suggestion. Only the weather suggestion should be shown. This patch
modifies to the muxer for that.
* This modifies `UrlbarView.#rowLabel()` to show the "Top pick" (a.k.a. best
match) label for keyword-based weather suggestions, in addition to zero-prefix
suggestions like we currently do.
* This modifies the remote settings client so it becomes enabled when keyword-
based weather suggestions are enabled, so that the config can be accessed.
Depends on D168738
Differential Revision: https://phabricator.services.mozilla.com/D168757
