STR

1. Enable update2 prefs
2. Open the view
3. Click a one-off
4. With the view still open, click a one-off again (same or different one-off, doesn't matter)

This error is logged in the console:

Can't start recording from event type: click UrlbarController.jsm:740
    start resource:///modules/UrlbarController.jsm:740
    startQuery resource:///modules/UrlbarInput.jsm:1053
    handleSearchCommand resource:///modules/UrlbarSearchOneOffs.jsm:125
    _on_click resource:///modules/SearchOneOffs.jsm:1161
    handleEvent resource:///modules/SearchOneOffs.jsm:181

This might be worth fixing as part of bug 1654680, if not separately.

I went back and checked and this started with bug 1647888, which makes sense since it made the view stay open after clicking a one-off, but I haven't looked into why this happens only after clicking more than once. For completeness, here's the stack with https://hg.mozilla.org/mozilla-central/rev/a27b933d7a82 (bug 1647888):

Can't start recording from event type: click UrlbarController.jsm:754
    start resource:///modules/UrlbarController.jsm:754
    startQuery resource:///modules/UrlbarInput.jsm:1050
    oneOffsCommandHandler resource:///modules/UrlbarView.jsm:649
    oneOffsClickHandler resource:///modules/UrlbarView.jsm:678
    _on_click chrome://browser/content/search/search-one-offs.js:1124
    handleEvent chrome://browser/content/search/search-one-offs.js:173

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 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

https://hg.mozilla.org/mozilla-central/rev/a27cf293e768

I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?

Reproduced the issue on Firefox 81.0RC build with update2 prefs enabled.
Verified as fixed on latest Nightly 82.0a1 2020-09-17 under Ubuntu 18.04 64-bit.