Given the result span problem described in bug 1699211 and bug 1699607,
currently there's no way for quick suggest to accurately specify the last index
as its suggested index.
Differential Revision: https://phabricator.services.mozilla.com/D109571
BrowserTestUtils.promiseAlertDialog and friends account for commonDialog.xhtml,
but not other dialogs which go through gDialogBox. This fixes that by adding a
inWindowDialog option to promiseAlertDialog. I don't like this solution very
much - it requires all of these dialogs to fire the event themselves. An
alternative might be putting this code in some file which these all include,
but given how small the code is that feels like overkill. Alternatives welcome.
Differential Revision: https://phabricator.services.mozilla.com/D109674
The matching logic can be simplified since we want exact matches and not prefix
matches. There's no need to confirm that the query string is in a candidate
result's list of keywords because by its nature the process of looking up the
query in the tree confirms that the query is equal to some keyword. If the
lookup finds a result, then necessarily the query matches a keyword.
I changed lookup from recursive to iterative. It might be a little faster and
it's not really harder to understand.
I also moved the full keyword computation out of the keyword tree and into
UrlbarQuickSuggest. It was a little hacky how KeywordTree accessed
`UrlbarQuickSuggest._results` during its lookup, and it forced the test to have
to set up `UrlbarQuickSuggest._results`. And big picture, it's not the keyword
tree's job to compute the full keyword/suggestion.
While working on all of this, `test_flatten` started failing when it calls
`basicChecks` because the flattened tree wasn't correct, so I rewrote and
simplified the flatten routine. It's no longer necessary for `RESULT_KEY` to be
in a map all by itself. Instead, it's treated like an ordinary char in the
context of flattening, so now it's more like a sentinel or suffix than a key.
Finally, I removed the "test1" and "test2" data in the test because I added them
when I thought they tested bug 1697678, but they don't actually. I don't think
they're testing anything useful.
Depends on D108683
Differential Revision: https://phabricator.services.mozilla.com/D108564
This also fixes a potential problem when deduping SERPs against form history:
We're creating SERP URLs based on the lowercased version of SERP terms instead
of the terms as is. That means we won't detect example.com/?q=foo and
example.com/?q=FOO as being dupes, but I think we should.
I updated the test to check for leading/trailing spaces as well as case.
Differential Revision: https://phabricator.services.mozilla.com/D107164
This fixes the two a11y problems with quick suggest results:
* When their help button is present, they aren't recognized as a listbox
option. That has a couple of consequences: They aren't read as an "<index> of
<size>" option, and they're read as an autocompleted URL instead of their
title.
* Their help button is read as its URL instead of its label. (The button has a
URL that's loaded when you click it.)
Fixing the second problem is easy, just give the help button an ID.
The first problem is trickier. It's due to the fact that when the help button is
present in the actual row, the "logical" row -- the part that's selectable and
looks like the main part of the row -- is not the row itself but rather one of
its children. So the rows container with `role=listbox` doesn't have the
selectable part as a direct child. To fix that, I added `role=option` to the
selectable part and `role=presentation` to the row itself.
Aside from these fixes, another possibility is to include the row's help button
as an option too, instead of as a button. I chose not to do that because it's
really a button and not a row/result, and also we have precedent with tip
results, which have similar buttons that we treat like this.
Note that the help button is *not* read on hover, only when keyboard selected.
That's a known bug we encountered in tips or interventions, but I can't find the
bug.
Depends on D106559
Differential Revision: https://phabricator.services.mozilla.com/D106712
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
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
