This removes `UrlbarProvider.pickResult()` and `blockResult()` in favor of
handling picks and dismissals through `onEngagement()`. A number of providers
use those two methods, so this revision touches a lot of files.
Handling dismissals through `onEngagement()` means `UrlbarInput.pickResult()`
can no longer tell whether a result is successfully dismissed, so it can't
remove the result anymore. (Maybe `onEngagement()` could return some value
indicating it dismissed the result, but I don't want to go down that road.)
Instead, I split `UrlbarController.handleDeleteEntry()` into two methods: a
public one that removes the result and notifies listeners, and a private one
that handles dismissing the selected result internally in
UrlbarController. Providers that have dismissable results should now implement
`onEngagement()` and call `controller.removeResult()`.
I made some other improvements to engagement handling. There's still room for
more but this patch is big enough already.
Other notable changes:
Include the engaged result in engagement notifications so providers have easy
access to it and can respond to clicks and dismissals more easily. That also
lets us stop passing `selIndex` and `provider` to `engagementEvent.record()`
since now it can compute those from the passed-in result.
Add the concept of `isSessionOngoing` to engagement notifications so providers
can tell whether an engagement ended the search session. Right now, providers
like quick suggest that record a bunch of provider-specific legacy telemetry
assume that `onEngagement()` ends the session, but that's no longer true.
Unify result buttons and result menu commands by setting
`element.dataset.command` on buttons (hopefully we can remove buttons soon, at
least the ones that aren't tip buttons)
Make sure we always notify providers on engagement even on dismissals or
when skipping legacy telemetry
Move dismissal of restyled search suggestions and history results from
`UrlbarController.handleDeleteEntry()` to the Places provider
Move dismissal of form history results from
`UrlbarController.handleDeleteEntry()` to the search suggestions provider
In the Places provider, remove the unused `_addSearchEngineMatch()` method. Also
remove the code in the "searchengine" case that creates a non-search-history
result. This code is unreached because the only time the provider creates a
"searchengine" match it also sets `isSearchHistory` to true.
In `UrlbarTestUtils.promiseAutocompleteResultPopup()`, change the default value
of the `fireInputEvent` param from false to true. This is necessary because
without a starting input event, the start event info in `engagementEvent` will
be null, so when `engagementEvent.record()` is called at the end of the
engagement, it will bail, and providers will not be notified of the engagement.
IMO true is a better default value anyway because input events will typically be
fired when the user performs a search.
Differential Revision: https://phabricator.services.mozilla.com/D174941
***
Bug 1821106 - SearchEngine.getResultDomain's responseType parameter is never used and the function needs renaming ,Comment is updated r=standard8
Differential Revision: https://phabricator.services.mozilla.com/D172293
In the future, due to the result menu there may be other engagement types that
do not close the view, so we may need to revisit this, but for now the fix is
pretty simple.
Differential Revision: https://phabricator.services.mozilla.com/D174038
This detects when the user is on a VPN and treats it the same as when the user
is offline: If a fetch is triggered, `QuickSuggest.weather.suggestion` is set to
null, and when the VPN is disconnected, a new fetch is triggered.
That means if a successful fetch happens before the user connects to the VPN,
Firefox will continue to show that accurate suggestion for the full fetch period
(30 min), even after the user connects to the VPN. The first time a fetch is
attempted while the VPN is active, the suggestion will be set to null, and
Firefox will stop showing it. Once the user turns off the VPN, a new fetch will
be triggered and the new accurate suggestion will be shown.
Unfortunately Firefox's VPN detection only works on Windows.
If you need to test weather suggestions using a VPN, you can run the following
JS in the browser console first. It will disable VPN detection.
```
QuickSuggest._test_linkService = {};
```
Differential Revision: https://phabricator.services.mozilla.com/D173232
This listens for some observer service notifications so we can re-fetch the
weather suggestion after wake and coming online, without having to wait for the
timer to fire. Please see the bug for background.
I changed the interval (repeating timer) to a timeout (non-repeating timer)
since the timer needs to be recreated on wake if the wake happens before the
start of the next fetch period.
Differential Revision: https://phabricator.services.mozilla.com/D172844
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 patch modifies existing Glean urlbar abandonment, engagement, and
impression events by including a weather suggestion.
This patch also adds a new telemetry scalar url.picked.weather to the legacy
telemetry system.
Differential Revision: https://phabricator.services.mozilla.com/D169225
