moz_inputhistory no longer reflects awesomebar usage

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
normal
RESOLVED FIXED
Last month
22 days ago

People

(Reporter: simon+mozilla, Assigned: mak)

Tracking

({regression})

68 Branch
Firefox 69
Desktop
All
Points:
3
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox67 unaffected, firefox68+ verified, firefox69 verified)

Details

Attachments

(2 attachments)

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

[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

Assignee: nobody → mak77
Status: NEW → ASSIGNED
Iteration: --- → 69.3 - Jun 10 - 23
Points: --- → 3
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/c8b11404e7a1
Reimplement the inputHistory feature in the Quantum Bar. r=adw
Regressions: 1560417
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69

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:
Attachment #9072892 - Flags: approval-mozilla-beta?

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+

Flags: needinfo?(andrei.vaida)
Attachment #9072892 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
Flags: needinfo?(andrei.vaida)
Flags: needinfo?(aflorinescu)

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.

Flags: qe-verify+
Flags: needinfo?(aflorinescu)

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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

Flags: needinfo?(simon+mozilla)

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)

Flags: needinfo?(simon+mozilla)

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.

Status: REOPENED → RESOLVED
Closed: Last month24 days ago
Resolution: --- → FIXED
Blocks: 1562585

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

Regressions: 1562585

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

Keywords: regression
You need to log in before you can comment on or make changes to this bug.