Since the switch to quantumbar in beta 68 moz_inputhistory in places.sqlite is no longer properly updated when typing in (partial) URLs and selecting entries.
On a fresh profile it stays completely empty.

To be investigated urgently, QB is not sending autocomplete-will-enter-text, and thus not updating adaptive history.

[Tracking Requested - why for this release]: Important feature not working as expected

(In reply to Marco Bonardo [::mak] from comment #3)

also, because we don't send autocomplete-did-enter-text, BrowserUserTelemetry is not sending all info.
https://searchfox.org/mozilla-central/rev/e42e1a1be58abbd81efd8d78d6d0699979f43138/browser/modules/BrowserUsageTelemetry.jsm#317

note: we don't necessarily need to reuse the existing path/code, indeed it may be simpler to directly execute the query in js, and call into BrowserUsageTelemetry.jsm

The BrowserUsageTelemetry part has already been reimplemented here:

https://searchfox.org/mozilla-central/rev/e42e1a1be58abbd81efd8d78d6d0699979f43138/browser/components/urlbar/UrlbarController.jsm#475-486

these tests don't cover the feature properly, they should be moved to browser-chrome
https://searchfox.org/mozilla-central/search?q=test_adaptive

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

Comment on attachment 9072892 [details]
Bug 1559686 - Reimplement the inputHistory feature in the Quantum Bar. r=adw!

Beta/Release Uplift Approval Request

• User impact if declined: Input history is broken. we use input history to provide better top results in the urlbar, that means the urlbar stopped being that awesome.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change in itself is quite simple.
  The only problematic part of the patch is that the automated test takes a relatively long time to run, indeed bug 1560417 indicates a possible timeout in test-verify. Though this fix is critical to us and the failure looks quite rare, so we can look into that later.
• String changes made/needed:

Comment on attachment 9072892 [details]
Bug 1559686 - Reimplement the inputHistory feature in the Quantum Bar. r=adw!

Must fix, NI Andrei to get SV to test this for any fallouts, Beta68+

https://hg.mozilla.org/releases/mozilla-beta/rev/4dc07e652294

Reproduced the issue on the affected 69.0a1 20190615095703 and 68.0b12, then verified the fix using:

• 69.0a1 20190624092246
• 68.0b13 20190624133534

on:

• Windows 7Pro x64
• Ubuntu 16.04
• Mac 10.14.5

Checked that the data in moz_inputhistory is populated correctly[1] when selecting history/bookmark result, both on mouse and keyboard selections. Also checked that moz_inputhistory is not updated when in private mode.

[1]On the correctness subject, I just queried the moz_inputhistory and moz_places tables from places.sqlite to observe if expected values have been added or not.

Checked that the data in moz_inputhistory is populated correctly[1] when selecting history/bookmark result, both on mouse and keyboard selections.[...]

[1]On the correctness subject, I just queried the moz_inputhistory and moz_places tables from places.sqlite to observe if expected values have been added or not.

Opening the awesomebar dropdown and selecting entries without prior input saves the URL of the opening tab as input, that doesn't seem right.

(In reply to Simon from comment #13)

Checked that the data in moz_inputhistory is populated correctly[1] when selecting history/bookmark result, both on mouse and keyboard selections.[...]

[1]On the correctness subject, I just queried the moz_inputhistory and moz_places tables from places.sqlite to observe if expected values have been added or not.

Opening the awesomebar dropdown and selecting entries without prior input saves the URL of the opening tab as input, that doesn't seem right.

Would you please elaborate? moz_inputhistory increments on history/bookmarked entries. What exactly is amiss here?

As you can see in the screenshot, visiting this site from different tabs (selecting entry in awesomebar dropdown) results in a new row with the URL of the currently open tab as input and separate use_count.

From my limited understanding it should update use_count on a row with empty input? (As it does, when the currently open tab is a new-tab)

please don't reopen verified fixed bugs, file a new one. This feature was lacking in tests, we just need to follow-up and add more test coverage. I also have another fix on the query side in queue.

I filed bug 1562585 to track the new problem reported by Simon.

Bugbug thinks this bug is a regression, but please revert this change in case of error.