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
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
This patch mainly does three things:
1. Changes the necessary CSS to meet the Proton spec.
2. Removes several calls to UrlbarInput.startLayoutBreakout(), because the Urlbar no longer expands when the panel is not open.
3. Introduces a [suppress-focus-border] attribute. This attribute hides the 2px focus ring around the Urlbar. This ensures that we don't flash the focus ring when the user clicks a Urlbar that will autoOpen, seeing as the open Urlbar no longer has a border. It also hides the focus border after the user presses Esc, as specified in Figma.
Differential Revision: https://phabricator.services.mozilla.com/D105097
With adding new feild to the `aParam`, `synthesizeNativeMouseClick` can
work as `synthesizenativeMouseClickAtCenter` too. Therefore, we can get
rid of the redundant API.
Additionally, this patch makes `synthesizeNativeMouseClickWithAPZ` can
take the new field for consistency between them.
Differential Revision: https://phabricator.services.mozilla.com/D105756
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 was a little more work than I first thought because fixing it uncovered
another problem: The recurse logic in the muxer isn't quite right. There are a
couple of problems actually:
1. By re-using the results from children that did not fill up, we skip updating
`stateCopy` (and therefore `state`), which messes up subsequent buckets in
the recursion because they're working with the wrong state.
2. By simply assigning `state = stateCopy` after handling children that didn't
fill up, we're not really doing anything because at that point the function
is done. The caller and subsequent buckets in the recursion won't see the
updated state. We need to update `state` in place.
These problems were revealed in test_resultBuckets.js, which is pretty thorough.
To fix the actual problem that the bug is about (not deduping remote suggestions
and form history), we just need to keep a set of suggestions that the muxer has
seen so far, and then `_canAddResult` can discard dupe suggestions. This patch
adds `state.suggestions` for that, and it includes form history, remote
suggestions, and the heuristic query when it's a search result. This way the
relative ordering of form history vs. remote suggestions doesn't matter. We'll
dedupe whichever comes later.
A bunch of tasks in test_resultBuckets.js needed to be updated to account for
this because they were incorrectly not expecting dupes to be removed.
Differential Revision: https://phabricator.services.mozilla.com/D106030
It turns out we're going to hardcode user-facing strings for the Quick Suggest
experiment, so help buttons need to allow their `title` attribute to be set
directly. This patch leaves `data-l10n-id` support because ultimately that's
what we'll want to use for non-experiment features. I didn't bother only setting
one or the other if both exist because we're never going to use both at the same
time, and it's not worth the code IMO.
Depends on D105095
Differential Revision: https://phabricator.services.mozilla.com/D105679
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
The problem is that the test creates and registers many providers but never
unregisters them. Usually that's not a problem since test providers have random
names and test query contexts are created with the `providers` option. But
sometimes two different providers end up with the same name because
`Math.random() * 100000` ends up being the same. Therefore a context can end up
with two (duplicate) providers when there should be only one, which means
`context.results` ends up with two copies of each result.
This patch makes several changes:
* test_resultBuckets.js now unregisters providers.
* Stop using `Math.random()` as the basis for making random test provider
names. Instead, use UUIDs.
* Add a `registerCleanupFunction` in head.js for unregistering test providers
(even though that wouldn't have fixed this bug).
* Make `registerBasicTestProvider` return the provider instead of its name so
that the provider can be passed to
`UrlbarProvidersManager.unregisterProvider()`.
Differential Revision: https://phabricator.services.mozilla.com/D104929
The urls where an OpenSearch engine can be loaded from are already limited in LinkHandlerChild. This is cleaning up and simplifying what the OpenSearchEngine allows, and as a result allows the load path handling to be greatly simplified.
The test changes are due to no longer allowing chrome or file protocols. For future, we probably want to move away from OpenSearch for most of these, but the changes will make it easier to find the places to update.
Differential Revision: https://phabricator.services.mozilla.com/D104010
Summary of changes:
* Replace the `matchBuckets` pref with `resultBuckets`.
* `resultBuckets` stores a JSON'ed root result bucket object. See the big
javadoc above `makeResultBuckets` in UrlbarPrefs for details.
* Convert existing result groups to more granular groups. This lets us remove
the heuristic-ordering logic in the muxer. It also lets us fix a subtle
inconsistency with regard to remote suggestions and form history; see the
removal of the two comments that start with "Note that the second form history
result appears after the remote suggestions" and "Note that the remote
suggestions appear in between the two form history results" in
test_search_suggestions.js.
* Unlike `matchBuckets`, `resultBuckets` stores *all* buckets, including the
heuristic at the beginning. Modify the muxer so that it discards heuristic
results that are not the first result.
Depends on D103137
Differential Revision: https://phabricator.services.mozilla.com/D99281
Introduce a new `browser.urlbar.showSearchSuggestionsFirst` boolean pref that
determines whether search suggestions are shown before general results.
This keeps the `matchBuckets` pref. I could have removed it since the only thing
we're using it for right now is to tell whether suggestions are shown first. The
reason I didn't remove it is because ultimately we do want a `matchBuckets` or
`resultBuckets` pref so we can experiment with different results compositions
using simple pref-flip studies. Hopefully bug 1676469 will land soon and we'll
replace `matchBuckets` with `resultBuckets`, but in the meantime I think we
should keep `matchBuckets` around.
This also removes some `browser.urlbar.matchBuckets` assignments in tests that
don't actually depend on it. For tests that do depend on it, I changed them so
they set `showSearchSuggestionsFirst` now.
Differential Revision: https://phabricator.services.mozilla.com/D103137
Avoid the cost of highligthing unvisited heuristic url results, since the whole
string would just be copied over and highlighted, paying an unnecessary cost.
Note, here we could go with an HIGHLIGHT.ALL mode, to retain the current behavior,
but highlighting the full url just makes it less readable, and we're not adding
anything to it, so highligting the typed part is not useful regardless.
Also don't try to autofill very long strings, it's expensive and not useful,
since the autofilled part would be out of screen anyway.
Differential Revision: https://phabricator.services.mozilla.com/D102485
When the user unchecks the "Show search suggestions before history results" pref,
we change browser.urlbar.matchBuckets to general:5;suggestions:Infinity.
When the code inverted the buckets, it put Infinity suggestions before general
results, pushing them away.
That pref could also be modified by the users or an experiment, so we can't just
set a suggestions limit from the default value (4 at this time).
The safest solution seems to be to get the results, then transplant suggestions
at the top, that allows to keep the matchBuckets defined number of general
results and fill remaining space above them with suggestions.
Differential Revision: https://phabricator.services.mozilla.com/D102346
Having browser.urlbar.extension.enabled be a hidden pref was causing issues with the new experimental APIs and their tests. Both the APIs and their tests first read the value of the pref before modifying it so it can later be restored to its default value. The default value of a hidden pref is undefined, which was causing errors. It's not a particularly sensitive pref, so I think unhiding it is preferable to finding a workaround to get the APIs/tests working with hidden prefs.
Differential Revision: https://phabricator.services.mozilla.com/D101799
Having browser.urlbar.extension.enabled be a hidden pref was causing issues with the new experimental APIs and their tests. Both the APIs and their tests first read the value of the pref before modifying it so it can later be restored to its default value. The default value of a hidden pref is undefined, which was causing errors. It's not a particularly sensitive pref, so I think unhiding it is preferable to finding a workaround to get the APIs/tests working with hidden prefs.
Differential Revision: https://phabricator.services.mozilla.com/D101799
This was a little harder than it seemed like it should be because we show/hide
the title separator in two places, in `UrlbarView.updateRow` and in the CSS.
This patch gets rid of the show/hide in `updateRow`, so now we show/hide only in
the CSS. The decision to show/hide in `updateRow` was based on whether the
result has action text (`actionSetter`) or is a URL (`setURL`). We already had a
`has-url` attribute that corresponds directly to `setURL`, so adding a similar
`has-action` attribute that corresponds to `actionSetter` lets us show/hide only
in the CSS.
The second part of this patch is to actually fix the bug. For that, the existing
`show-action-text` attribute does part of what we want in the CSS: It forces the
action to be shown when a one-off is selected and there's no selected row. In
addition to that, we need to show the action when both a restyled search and a
one-off are selected, so this adds a new `restyled-search` attribute. We need
both attributes because we do not want to show the action for a restyled search
when some other row plus a one-off are selected (to match the current behavior).
Depends on D97843
Differential Revision: https://phabricator.services.mozilla.com/D98429
Fix a race condition with Korean IME, where it may submit delayed text after
Enter has been handled. The patch delays events if composition is still ongoing
and avoids using the selected element or the last resultForValue if it's not
yet complete by the time we submit the text.
Unfortunately this cannot be tested automatically in mochitests because it
depends on a native behavior of the IME that synthesize methods can't reproduce.
Additionally this fixes Bug 1679697 by ensuring Search Mode is not dismissed
by IME and the urlbar value is proper when confirming Tab-to-search.
This part comes with tests.
Differential Revision: https://phabricator.services.mozilla.com/D98768
This was a little harder than it seemed like it should be because we show/hide
the title separator in two places, in `UrlbarView.updateRow` and in the CSS.
This patch gets rid of the show/hide in `updateRow`, so now we show/hide only in
the CSS. The decision to show/hide in `updateRow` was based on whether the
result has action text (`actionSetter`) or is a URL (`setURL`). We already had a
`has-url` attribute that corresponds directly to `setURL`, so adding a similar
`has-action` attribute that corresponds to `actionSetter` lets us show/hide only
in the CSS.
The second part of this patch is to actually fix the bug. For that, the existing
`show-action-text` attribute does what we want in the CSS; the only problem is
that we currently set it only when there's no selected row, but we need to also
set it when there's no selected row but a one-off is selected. We have a similar
block -- the one with a comment about restyling the heuristic to look like a
search result -- so I removed the block that currently sets/removes the
attribute and moved the set/removal there. I also renamed the attribute
`restyled-search` to better semantically describe what's happening, but if you
disagree I can restore the old name.
Depends on D97843
Differential Revision: https://phabricator.services.mozilla.com/D98429
