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
Some random thoughts:
* This is a minimal implementation - there were plans to expand this with autocomplete support that we never got around to
* I built this just from reading docs + poking around in the urlbar code, so there might be a more desireable way to do all of this
* We've gone back and forth between calling this "contextual search" and "site specific search," we should probably pick a name and stick to it
* There were never any design specs for this so the UI/UX was based off of existing urlbar results as they appeared in Flowstate
* There were some open questions around how we treat installing opensearch engines, since how they are handled here seems to differ from how we use them elsewhere
* I don't remember the reasoning for showing this result last in the urlbar, we may want to move it elsewhere
Differential Revision: https://phabricator.services.mozilla.com/D159052
This makes Merino opt out on Beta. There are two different parts:
1. Decide what "Beta" means. After discussing this with RyanVM, I'm using the
same definition [used by telemetry](https://searchfox.org/mozilla-central/rev/2f47e3dacf0d773e9c7f363cecf10cfbea490679/toolkit/components/telemetry/app/TelemetryControllerBase.jsm#103,112-114): (a) if `MOZ_UPDATE_CHANNEL` is "beta"
or (b) if it's "release" and `app.update.channel` is "beta". The latter case
is true for RC builds delivered to the Beta channel. I moved the relevant
telemetry logic to `AppConstants` so I can easily use it too. Bug 1435753 has
context on this logic w/r/t telemetry.
2. Change the Merino default so it's enabled on Beta in the offline scenario. I
kept the online scenario's disabled default since the only point of
delivering the online scenario to the user now is to prompt them to opt in to
Merino. This change is in UrlbarPrefs.sys.mjs.
The rest of the patch updates tests.
The effect of this patch will be to use a new default value of true for the
`quicksuggest.dataCollection.enabled` pref on Beta in the offline scenario. If
the user didn't touch the pref at all, then its previous default value was
false, and the new default will now be true.
If the user enabled the pref, it will remain enabled. If the user enabled and
then disabled it, it will remain disabled. That's because the pref is sticky, so
once it has a value on the user branch, it will keep that value. This patch only
changes the value of the pref on the default branch, so it won't override the
user's previous choice since that is set on the user branch.
Differential Revision: https://phabricator.services.mozilla.com/D162353
This adds a weather feature to quick suggest. It periodically fetches a weather
suggestion from Merino. UrlbarProviderQuickSuggest shows the suggestion when the
search string is empty ("zero prefix").
The implementation of the UrlbarResult returned by UrlbarProviderQuickSuggest is
only temporary. Mandy is working on the final UI in
[SNT-323](https://mozilla-hub.atlassian.net/browse/SNT-323). Landing a temporary
implementation allows Mandy to base her patch on it and trigger real weather
suggestions from Merino to test her implementation against. It also lets people
on the team test weather suggestions without having to wait for the final UI to
land.
I added the following prefs and Nimbus variable to control the feature. It will
initially be rolled out in an experiment, so we need a Nimbus variable. In the
initial experiment, users will be able to dismiss the suggestion but not toggle
a checkbox in about:preferences.
* `weatherFeatureGate` - Nimbus variable that controls the whole feature
* `browser.urlbar.weather.featureGate` - Fallback pref for the Nimbus variable
* `browser.urlbar.suggest.weather` - When the feature gate pref is true, this
determines whether the suggestion should be shown. In a future patch, we'll
flip this to false when users dismiss the suggestion.
I set the fetch interval to 30 minutes. That seems reasonable considering that
the suggestion contains the current temperature and weather. Merino will set
caching headers appropriately so that Firefox won't actually make a new network
request if the previously fetched suggestion is new enough.
Depends on D161368
Differential Revision: https://phabricator.services.mozilla.com/D161410
This adds a weather feature to quick suggest. It periodically fetches a weather
suggestion from Merino. UrlbarProviderQuickSuggest shows the suggestion when the
search string is empty ("zero prefix").
The implementation of the UrlbarResult returned by UrlbarProviderQuickSuggest is
only temporary. Mandy is working on the final UI in
[SNT-323](https://mozilla-hub.atlassian.net/browse/SNT-323). Landing a temporary
implementation allows Mandy to base her patch on it and trigger real weather
suggestions from Merino to test her implementation against. It also lets people
on the team test weather suggestions without having to wait for the final UI to
land.
I added the following prefs and Nimbus variable to control the feature. It will
initially be rolled out in an experiment, so we need a Nimbus variable. In the
initial experiment, users will be able to dismiss the suggestion but not toggle
a checkbox in about:preferences.
* `weatherFeatureGate` - Nimbus variable that controls the whole feature
* `browser.urlbar.weather.featureGate` - Fallback pref for the Nimbus variable
* `browser.urlbar.suggest.weather` - When the feature gate pref is true, this
determines whether the suggestion should be shown. In a future patch, we'll
flip this to false when users dismiss the suggestion.
I set the fetch interval to 30 minutes. That seems reasonable considering that
the suggestion contains the current temperature and weather. Merino will set
caching headers appropriately so that Firefox won't actually make a new network
request if the previously fetched suggestion is new enough.
Depends on D161368
Differential Revision: https://phabricator.services.mozilla.com/D161410
This does the following:
* Moves quick suggest initialization from UrlbarQuickSuggest to QuickSuggest
* Renames UrlbarQuickSuggest.sys.mjs to QuickSuggestRemoteSettingsClient.sys.mjs, so now this file is focused only on remote settings
* Makes QuickSuggest create an instance of QuickSuggestRemoteSettingsClient and keep it as `QuickSuggest.remoteSettings`
* Moves latency telemetry from UrlbarProviderQuickSuggest into QuickSuggestRemoteSettingsClient
* Changes the ad hoc logger used in QuickSuggestRemoteSettingsClient to a proper urlbar-style logger
* Updates consumers to use `QuickSuggest.remoteSettings` instead of UrlbarQuickSuggest
Please see bug 1798595 for details.
Depends on D160985
Differential Revision: https://phabricator.services.mozilla.com/D160986
This reverts the fix to bug 1731373 and instead makes Firefox Suggest wait for
TelemetryEnvironment to finish initializing before it starts to update its
preferences. That's what I should have done in the first place, no need for an
observer notification or for TelemetryEnvironment to have to know any details
about Suggest prefs.
This fixes the bug (bug 1796202) and should also avoid the problem for any other
Suggest prefs we add to TelemetryEnvironment in the future.
Differential Revision: https://phabricator.services.mozilla.com/D159820
Change the behavior of the QuickActions provider, so that setting the
pref `quickactions.enabled` to false will prevent showing quick action
results in all contexts, while setting `suggest.quickactions` to false
will only prevent showing quick action results in the default search
mode (i.e., quick action results will still appear in the Quick Actions
search mode enabled by typing `> ` in the urlbar).
Differential Revision: https://phabricator.services.mozilla.com/D157702
