This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
There are a couple of things that would make collecting engagement telemetry
like impressions and clicks a lot easier: having the query context and details
of the picked result. We need to collect this exact telemetry for the top sites
and quick suggest experiments. For quick suggest in particular, we need the
index of the quick suggest result for the impression telemetry. There's no good
way to get that right now because although the quick suggest is always last, the
index depends on the muxer and the number of final results.
Details of the picked result is easy because there's already a `details` object
with that info when the controller's telemetry event tells the providers manager
to notify providers of an engagement.
The query context is a little harder, but we can take it from the controller.
It's not guaranteed to be defined at the time that `onEngagement` is called for
`start`, so I tried to make that clear in the javadoc. Since it may not be
defined on `start`, `onEngagement` still needs the `isPrivate` param even though
the context also has an `isPrivate` property.
With this patch, we should be able to record clicks in providers without having
to call `pickResult` for every provider. `pickResult` would be the other obvious
place to record picks on results in providers.
Depends on D105815
Differential Revision: https://phabricator.services.mozilla.com/D106060
This supports a new `helpUrl` payload property on all results. It causes results
in the view to have a help button that can be selected and picked independently
of the main part of the result. When picked, the help button loads the
`helpUrl`. It looks and acts the same as the help buttons we already have for
tip results.
The help button should be flush with the trailing edge of the result row, and it
should be selectable independently from the main part of the result. To achieve
that without disrupting things too much, I create the button inside of
`.urlbarView-row` but outside of `.urlbarView-row-inner`. The "main" part of the
row is `.urlbarView-row-inner`. I made `.urlbarView-row` have `display: flex` so
the the inner part can have `flex: 1` so it can fill up the entire row except
for the help button.
This also reworks view selection a little so that for each row, we look for
selectable elements in the row instead of assuming that the row itself is
selectable. That also lets us remove a couple of special cases for tip and
dynamic results.
Differential Revision: https://phabricator.services.mozilla.com/D105095
This converts FX_URLBAR_SELECTED_RESULT_TYPE_2, FX_URLBAR_SELECTED_RESULT_INDEX
and the correlation between them FX_URLBAR_SELECTED_RESULT_INDEX_BY_TYPE_2 to
keyed scalars, that are nicer to use and analyze.
They are converted to one keyed scalar per result type, tracking the number
of times that type was picked per urlbar index.
The sums (count per type or per index) can still be derived from this structure.
Differential Revision: https://phabricator.services.mozilla.com/D94498
This is a pretty simple implementation of the approach discussed in the bug. When a tab-to-search result is shown, we announce it to screen readers. We keep track of which engines are announced to be sure we don't keep announcing the same engine as the user types.
This approach is maybe slightly crude, but I didn't find a working elegant approach. One approach I considered is checking for tab-to-search results in the loop in UrlbarView._updateResults. After the loop is finished, if we found a tab-to-search result, we go back and change the aria-label on the action text of the prior result to something like "Visit, or press Tab to search with { $engine }. This didn't work because we don't read action text for the heuristic result as the user types. This is presumbably to avoid disrupting the user as they type. This is what my patch does regardless, however... Since Jamie was skeptical about whether we should announce this at all, I put this behaviour behind a default-true pref, browser.urlbar.tabToSearch.accessibility.announceResults.
Differential Revision: https://phabricator.services.mozilla.com/D93451
* Always update the `_searchModesByBrowser` map when entering/exiting search
mode, not only for non-selected browsers, so that search mode can be saved and
restored properly per tab.
* Rename `setSearchMode` to `_updateSearchModeUI` and make it only update the UI.
* Add a new `setSearchMode` method that takes a browser and updates the map.
* Add `getSearchMode` so that SessionStore can get the search mode for a given
browser.
* Add a `searchMode` getter and setter for convenience. They call
`getSearchMode` and `setSearchMode` with the selected browser.
Differential Revision: https://phabricator.services.mozilla.com/D91910
This adds tab-to-search telemetry, both for the new tabtosearch search mode entry point and for tabtosearch results in our usual Urlbar result-selection scalars. I also added a subtest in browser_urlbar_event_telemetry, but realized as I was writing it that it was not useful. We don't consider entering search more as the end of an engagement, so tab-to-search results will not appear in event telemetry. We already considered this in bug 1654680 and resolved it by adding detailed urlbar.searchmode.* scalars, so I don't consider it a blocker. I left the new subtest in since it was mostly done anyways and it can't hurt.
Differential Revision: https://phabricator.services.mozilla.com/D91469
- always show search suggestions first in search mode
- use restyleSearches only in search mode, to get cleaner history results and dedupe against search history
- filter redirects differently depending on restyleSearches
Differential Revision: https://phabricator.services.mozilla.com/D90719
Summary of major changes:
* Bookmarks, history, and tabs restriction chars now enter search mode. I added
a method to UrlbarProviderHeuristicFallback to return a result with a keyword
when one of these is used.
* This fixes other bugs like recognizing aliases that are entered at the
beginning of non-empty search strings, and not quasi-re-entering search mode
when search mode is already entered and you type another alias.
* The heuristic now determines whether we enter search mode, similar to how it
also determines whether we autofill. When the heuristic has a keyword but no
keyword offer, and the keyword is one of the recognized search mode keywords,
then we enter search mode, cancel the current query, and start a new query
with the remainder of the search string after the keyword.
* I slightly changed how we detect an alias, but only when update2 is
enabled. Now, an alias must be followed by a space; otherwise, the alias is
not recognized and instead just remains part of the seach string. Because if
we don't do that, then you end up in a strange situation after typing an alias
but before pressing space: The heuristic says "Search with <engine with the
alias>", but we haven't entered search mode yet because you haven't typed a
space yet. This is true for both @aliaes and non-@aliases.
* A consequence of the previous point is that we can still autofill @aliases
with a trailing space, which IMO is important. Then, once the user types any
char (space or not), we immediately enter search mode with the query being
whatever char they typed. This is less important after bug 1658605 landed, but
it's still good to have.
* Previously, `UrlbarView.onQueryResults` called UrlbarInput in order to
autofill after the first result is received. This is circuitous becaue the
input already has an `onFirstResult` method, which I now use to enter search
mode when appropriate. So I moved the autofill call from UrlbarView to
`UrlbarInput.onFirstResult`.
* As I mentioned, I improved some test framework and simplified some related
product (non-test) code. For example:
* I removed `UrlbarUtils.KEYWORD_OFFER.NONE` in favor of just leaving
`keywordOffer` as `undefined`.
* `tailOffsetIndex` can now be `undefined` if it's not relevant.
* I removed empty-string `icon` properties from payloads in favor of
`undefined`.
* In tests, I ignore `undefined` but present properties in payloads so they
don't count when comparing payloads with `deepEqual`.
* We weren't previously comparing `result.source` and `result.type` in
xpcshell tests, and that's important IMO, so I added checks for those and
updated tests.
* `isSearchHistory` is redundant, so I removed it. For form history, we
should be checking `result.source == HISTORY` and `result.type == SEARCH`.
* A bunch of tests needed to be updated for this new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D87944
Solving this is as simple as adding "click" to the list of events allowed to start an engagement event. Previously, we didn't have any clicks that could start an engagement event (although we allowed `mousedown` for focusing the Urlbar). Now, we have a few click events that start something that could be considered engagement: clicking a one off and clicking the exit button on the search mode indicator.
When engagementEvent.start() is called, [we bail](https://searchfox.org/mozilla-central/rev/ce21a13035623c1d349980057d09000e70669802/browser/components/urlbar/UrlbarController.jsm#720) if we're currently in an engagement. I can no longer trigger the error in the bug in regular Firefox use; I assume at the time this bug was filed, it was possible to record/discard an engagement by clicking the one-offs a second time. The second click would call `engagementEvent.start()` again and the error would be throw since we discarded the previous engagement event. This no longer seems to be the case. I can trigger it from tests though. That's because this is a common pattern in our tests:
```
await UrlbarTestUtils.promiseAutocompleteResultPopup({
window,
value: TEST_QUERY,
});
await UrlbarTestUtils.enterSearchMode(window);
```
If we don't include `fireInputEvent: true` in our call to `promiseAutocompleteResultPopup`, the view is opened without ever starting an engagement event. Then when `enterSearchMode` clicks a one-off, we call `UrlbarInput.startQuery`, which starts an engagement event. The error follows.
Adding click to the list of allowedEvents fixes this in tests and addresses any edge cases we might create in the future where the user is able to click a one-off without already being in an engagement event.
Depends on D87510
Differential Revision: https://phabricator.services.mozilla.com/D88480
We just need to start a new query on backspace, even when the input is empty.
I noticed that unlike backspace, clicking the close button will always start a
new query except when the view is closed. That means the close button was
already doing the right thing. It also means that the close button will not open
the view and show top sites when the view is already closed; however, with this
patch, backspace *will* open the view and show top sites if the view is closed.
That seems right to me despite the inconsistency since inputs in the urlbar
(including backspace) always cause the view to open.
Other changes:
* Make the `click_close` test task more similar to the `backspace` task: Open
the view both with and without a string instead of only with a string
* Some calls in the test didn't have an `await` like they should (maybe the
source of reported intermittent failures?)
Differential Revision: https://phabricator.services.mozilla.com/D86686
This patch changes the paramters to setSearchMode. The original patch to introduce search mode passed engineName to setSearchMode instead of the entire engine object. It was suggested in review that the nsISearchEngine be passed so we could run instanceof to distinguish it from a RESULT_TYPE. This patch reverses this and passes engineName instead through a destructured parameter.
In pickResult, we need to enter search mode synchronously based on the information in a result payload. Result payloads can't/shouldn't pass around complex objects like an nsISearchEngine, so we just pass engineName and the alias as strings. Since pickResult is synchronous, we can't use UrlbarSearchUtils to look up the engine based on the engineName. Besides, setSearchMode only uses engineName, so looking up the engine only to just use its name seems like a waste of resources.
This patch also disables autofill in search mode queries. Autofill was interfering with alias replacement. We were already half doing this (https://searchfox.org/mozilla-central/rev/26b13464c2beb26e0d864d561c30e817a85c348a/browser/components/urlbar/UrlbarController.jsm#391) but adding the searchMode check to UrlbarInput._maybeAutofillOnInput should resolve bug 1655473.
There's still one more bug I'm working through where the placeholder disappears after alias replacement. I though I'd get this out to start review regardless since we want to get the three patches discussed in Thursday's meeting out ASAP.
Differential Revision: https://phabricator.services.mozilla.com/D86389
This patch changes the paramters to setSearchMode. The original patch to introduce search mode passed engineName to setSearchMode instead of the entire engine object. It was suggested in review that the nsISearchEngine be passed so we could run instanceof to distinguish it from a RESULT_TYPE. This patch reverses this and passes engineName instead through a destructured parameter.
In pickResult, we need to enter search mode synchronously based on the information in a result payload. Result payloads can't/shouldn't pass around complex objects like an nsISearchEngine, so we just pass engineName and the alias as strings. Since pickResult is synchronous, we can't use UrlbarSearchUtils to look up the engine based on the engineName. Besides, setSearchMode only uses engineName, so looking up the engine only to just use its name seems like a waste of resources.
This patch also disables autofill in search mode queries. Autofill was interfering with alias replacement. We were already half doing this (https://searchfox.org/mozilla-central/rev/26b13464c2beb26e0d864d561c30e817a85c348a/browser/components/urlbar/UrlbarController.jsm#391) but adding the searchMode check to UrlbarInput._maybeAutofillOnInput should resolve bug 1655473.
There's still one more bug I'm working through where the placeholder disappears after alias replacement. I though I'd get this out to start review regardless since we want to get the three patches discussed in Thursday's meeting out ASAP.
Differential Revision: https://phabricator.services.mozilla.com/D86389
The base class retains the `popup` property, and now the `view` property is
entirely in the subclass. I defined some new methods so that the subclass can
easily customize behavior for a view that's not a popup. I used the name "view"
in these method names to refer to a generic view/panel. I didn't rename `popup`
`view` because the base class still assumes that `popup` is a `menupopup`.
We could/should probably get rid of the "compact" concept and instead specialize
the behavior even further in the subclass, but for simplicity's sake I left that
for now.
Depends on D84784
Differential Revision: https://phabricator.services.mozilla.com/D84785
The base class retains the `popup` property, and now the `view` property is
entirely in the subclass. I defined some new methods so that the subclass can
easily customize behavior for a view that's not a popup. I used the name "view"
in these method names to refer to a generic view/panel. I didn't rename `popup`
`view` because the base class still assumes that `popup` is a `menupopup`.
We could/should probably get rid of the "compact" concept and instead specialize
the behavior even further in the subclass, but for simplicity's sake I left that
for now.
Depends on D84784
Differential Revision: https://phabricator.services.mozilla.com/D84785
AFAICT this bug isn't reproducible anymore after bug 1623666. i.e., it's no
longer possible to show the history view. You can still see a history-like view
by typing ^ or a space, but in that case the first result is a search result,
not a history result, so it can't be deleted anyway. Nevertheless we should fix
this error.
Differential Revision: https://phabricator.services.mozilla.com/D79576
This is so that we can avoid needing mozSystemGroup (to get keypress for
non-printable keys), which in turn prevents racing with the native key event
listeners, see the second patch in bug 1624657.
This turned out to be a bit tricky, because we need to guarantee the ordering of
the search one-offs handling in the searchbar with the usual autocomplete-input
handling. We could try to move this to the popup subclass but this is already a
bigger patch than what I'd like.
We can also revert the customElements.js change I did in bug 1624657, as the bug
is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D69743
--HG--
extra : moz-landing-system : lando
