We need to start engagement event recording when the view opens due to `openViewOnFocus`. We already do for mouse clicks since we call `engagementEvent.start` from `_on_mousedown`. But we don't for the Ctrl/Command-L key shortcut. The shortcut command calls `openLocation` in browser.js, which calls `gURLBar.startQuery` but not `engagementEvent.start`.
Every time we call `engagementEvent.start`, we do it before calling `input.startQuery`. The one exception is in `input._on_drop` because there we just handle the dropped value directly instead of starting a new query with it.
The inverse is also mostly true, i.e., every time we call `input.startQuery`, we also call `engagementEvent.start`. The three exceptions are: in UITour (where it looks like we should be calling `urlbar.search` instead), in `UrlbarInput` after picking a keyword offer result, and in `openLocation` in browser.js (mentioned above). So really the only valid place is after picking a keyword entry.
So, it makes sense to move `engagementEvent.start()` into `input.startQuery` so that callers don't have to call it. I added an `event` param to `startQuery`, since `engagementEvent.start` needs one. I considered removing that need. It's possible, but then we would need a way to avoid calling `engagementEvent.start` in the keyword offer case, so `startQuery` would need something like a `suppressEngagementEvent` param. `event` basically functions as that, so I left it.
Another thing to point out about this patch is that I chose to record a "typed" value when the pageproxystate is invalid and the view opens due to `openViewOnFocus`. The view does not show the user's top sites in that case, so "topsites" seems wrong.
Differential Revision: https://phabricator.services.mozilla.com/D42749
--HG--
extra : moz-landing-system : lando
This test uncovered a couple of problems:
(1) UrlbarController.handleKeyNavigation relies on event.defaultPrevented to tell whether the one-offs handled the key event. That's a problem when combined with deferring the down arrow key.
handleKeyNavigation is called twice in that case. The first time, the event is deferred (so executeAction = false), and handleKeyNavigation calls event.preventDefault. The second time, the event is being replayed, but defaultPrevented is true from the previous call regardless of whether the one-offs actually handled the event.
So handleKeyNavigation always returns early because it thinks the one-offs always handled the event, so it never properly replays down arrow keys.
(2) UrlbarProviderUnifiedComplete's query promise is never resolved when the query is canceled. That's a problem in general of course but I tripped over it in this test because I need to check results after the query is canceled, and the test ended up hanging since UrlbarTestUtils waits for the query to finish in order to get its results.
It's not a problem in UnifiedComplete itself per se because of course awesomebar uses UnifiedComplete too, and it doesn't have this problem. The difference is that nsAutoCompleteController::StopSearch calls input->OnSearchComplete() (via PostSearchCleanup): https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1433
Quantumbar's UnifiedComplete provider is missing that behavior, so this patch adds it by resolving its query promise when the query is canceled.
Differential Revision: https://phabricator.services.mozilla.com/D29300
--HG--
extra : moz-landing-system : lando
This test uncovered a couple of problems:
(1) UrlbarController.handleKeyNavigation relies on event.defaultPrevented to tell whether the one-offs handled the key event. That's a problem when combined with deferring the down arrow key.
handleKeyNavigation is called twice in that case. The first time, the event is deferred (so executeAction = false), and handleKeyNavigation calls event.preventDefault. The second time, the event is being replayed, but defaultPrevented is true from the previous call regardless of whether the one-offs actually handled the event.
So handleKeyNavigation always returns early because it thinks the one-offs always handled the event, so it never properly replays down arrow keys.
(2) UrlbarProviderUnifiedComplete's query promise is never resolved when the query is canceled. That's a problem in general of course but I tripped over it in this test because I need to check results after the query is canceled, and the test ended up hanging since UrlbarTestUtils waits for the query to finish in order to get its results.
It's not a problem in UnifiedComplete itself per se because of course awesomebar uses UnifiedComplete too, and it doesn't have this problem. The difference is that nsAutoCompleteController::StopSearch calls input->OnSearchComplete() (via PostSearchCleanup): https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1433
Quantumbar's UnifiedComplete provider is missing that behavior, so this patch adds it by resolving its query promise when the query is canceled.
Differential Revision: https://phabricator.services.mozilla.com/D29300
--HG--
extra : moz-landing-system : lando
We need to handle autofilling the first result separately from autofilling results in general (which happens in UrlbarInput.setValueFromResult), so add a new UrlbarInput.autofillFirstResult method. The controller calls it instead of setValueFromResult. I ported the logic from nsAutoCompleteController, as described in the bug.
Other changes are related to the new test for this.
As part of this work, I was interested in learning how awesomebar handles browser_autoFill_typed.js, so I added it to the legacy tests, with a small tweak in the test for awesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D26852
--HG--
extra : moz-landing-system : lando
This doesn't enable the rightClick option for telemetry reporting as that is complicated to support, see bug 1528250.
Differential Revision: https://phabricator.services.mozilla.com/D19951
--HG--
extra : moz-landing-system : lando
This makes the browser_UsageTelemetry_urlbar*.js tests pass for the all of the
FX_URLBAR_SELECTED_RESULT_* histograms apart from the "METHOD" one which will be handled
in bug 1500476.
I have handled the recording of telemetry in the controller, as this seems a better
location than BrowserUsageTelemetry.jsm due to needing to reach into the results and obtain
specific details.
Differential Revision: https://phabricator.services.mozilla.com/D19785
--HG--
extra : moz-landing-system : lando
