GitLab

This is the 16th refactoring CL aimed at reducing duplication and
inconsistency for classifying omnibox results.

The historyQuick provider compares the user input and the suggestion
text to find the corresponding matches during construction of the
ScoredHistoryMatch precursor to the suggestion's AutocompleteMatch. The
term matches are then used for both scoring and classifying.

With this CL, historyQuick classification uses the 'FindTermMatches' and
'ClassifyTermMatches' methods that other providers use. This improves
consistency with other providers at the cost of inconsistency with the
historyQuick provider's scoring.

The differences between current and this CL's classification:

1) Prefix matching. With this CL, if the input is an exact prefix of the
suggestion text, subsequent matching words in the suggestion text are
not bolded. E.g. for input 'x' and suggestion 'x x', before this CL,
both occurrences would be bolded; with this CL, only the first will be.

2) Midword matching. Before this CL, midword matches were allowed for
the URL host domain. E.g., for input 'x' and suggestion 'zxx.xx/xx',
before this CL, the first 5 occurrences would be bolded,
'z[xx].[xx]/[x]x'; with this CL, only the 3rd and 4th will be bolded,
'zxx.[x]x/[x]x'.

3) Input word-break separators. Before this CL, the user input was not
broken by symbols, though the suggest text was. E.g., for input 'x%x y'
and suggestion 'x%x x y%y y', before this CL, it would bold as '[x%x] x
[y]%[y] [y]'; with this CL, it will bold as '[x]%[x] [x] [y]%[y] [y]'.

All 3 changes apply to suggestion classification (bolding) only;
determining which suggestions to display and their ordering is
unaffected.

Re consistency with other providers: A user may see suggestions from
different providers with similar texts. E.g., the user input 'the' could
provide both search and historyQuick suggestions with texts 'the cake
ate the moon'. It would be surprising if such suggestions with the same
text were bolded differently; e.g. the search suggestion were bolded
'[the] cake ate the moon', whereas the historyQuick suggestion was
bolded '[the] cake ate [the] moon'.

Re inconsistency with historyQuick's scoring. Scoring is consistent with
the previous bolding; all previously bolded terms would either
contribute (positively or negatively) to the suggestions score or
disqualify the suggestion (e.g. 'm' disqualifies 'yahoo.com'). E.g., 'y
hoo' would bold both terms in the suggestion URL '[y]a[hoo].com', and
both would contribute to the score. With the classification changes,
only 'y' would be bolded, suggesting the 'hoo' term did not contribute
to scoring.

Bug: 366623
Change-Id: I478a9d4fcc63abe7aa55dba4274e8896d6bdc388
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1593717
Commit-Queue: manuk hovanesian <manukh@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#664505}