1752604 - Implement the MVP logic for deciding which quick suggest results are best matches

Status: VERIFIED FIXED

(Firefox :: Address Bar, task, P1)

Description

[Drew Willcoxon :adw]

Once we finalize how Suggest suggestions should become best matches for the MVP, we need to implement that logic. I wrote an MVP Engineering proposal here.

This bug decides the logic that sets suggestion.is_best_match to true; bug 1752470 looks for suggestion.is_best_match and sets result.isBestMatch and result.suggestedIndex = 1 on the result object created from the suggestion; and bug 1752251 creates the appropriate view DOM for results with isBestMatch.

Comment 1

[Drew Willcoxon :adw]

Attachment: Bug 1752604 - Implement the MVP logic for deciding which quick suggest results are best matches.

Comment 2

[Drew Willcoxon :adw]

Attachment: Bug 1752604 - Implement the MVP logic for deciding which quick suggest results are best matches.

This is based on the final best match MVP spec and the new configuration data
that Nan added to remote settings. Details on that are here:

• Best match spec, Matching Heuristics section
• Configuration Jira ticket
• Configuration GitHub PR

In summary, a quick suggest will be a best match when the following two
conditions are both true:

• The length of the user's search string (i.e., matched suggestion keyword) is

  = 4

• The suggestion is allowed to be a best match

This revision is pretty straightforward. The only complex thing is it includes a
config data validator that gives the config object reasonable defaults as much
as possible, mostly so that UrlbarQuickSuggest doesn't need to null-check and
type-check config properties every time it uses them. Of course it could just
assume the config has a certain schema, but that feels unsafe. Alternatively we
could add a version number to the config, but that wouldn't handle the case
where the config is not present at all for some reason.

I modified test_quicksuggest_bestMatch.js so that it relies on this new logic
throughout, instead of using the _test_is_quick_suggest property in the mock
suggestions.

Comment 3

[Drew Willcoxon :adw]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e0e1f445eae566f5838c9f4cea4a084915672aee

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b3b8027d4902
Implement the MVP logic for deciding which quick suggest results are best matches. r=daisuke

Comment 5

[Drew Willcoxon :adw]

STR for QA:

To trigger a suggestion as a best match, two things must be true:

• Your search string has to be at least 4 characters long.
• The suggestion must not be in the blocklist for best matches. Right now the blocklist includes the main www.amazon.com and en.wikipedia.org suggestions, the ones that link to their home pages.

1. Enable Firefox Suggest and best match (browser.urlbar.bestMatch.enabled)
2. Type amazon and verify the Amazon suggestion appears as a usual Suggest suggestion, not a best match
3. Type wikipedia and verify the Wikipedia suggestion appears as a usual Suggest suggestion, not a best match
4. Type bet and verify the Betty White Wikipedia suggestion appears as a usual Suggest suggestion, not a best match
5. Continue typing betty and verify that the suggestion now appears as a best match

Comment 6

[Marian-Vasile Laza]

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

Comment 7

[Carmen Fat [:cfat] - Ecosystem QA]

I have verified this issue on the latest Nightly 99.0a1 (Build ID: 20220304094153) on Windows 10 x64. macOS 10.15.7 and Linux Ubuntu 20.04 x64.

1. In order to verify this issue we have used the STR from comment 5.
2. The amazon and wikipedia keywords trigger only a Suggest suggestion, not a best match.
3. The keywords that don't redirect to a Homepage (such as betty, disney, apple etc.) trigger only Suggest suggestions IF less than 4 characters are typed in the Address Bar.

• If 4 or more characters are typed, then best match suggestions are displayed.