Choice of autocompletion candidates for HistoryQuickProvider
45 views
Skip to first unread message
Alexander Yashkin
Feb 1, 2017, 8:14:35 AM2/1/17
to Chromium-dev
Hi all.
I have questions regarding the choice of autocompletion candidates for HistoryQuickProvider (HQP).
As I see in code, the HQP is filled with URLs chosen by following criteria -
is visited in last 3 days OR is visited more than 4 times OR typed from omnibox at least once.
This is implemented in RowQualifiesAsSignificant function.
Also the same function is used to cull poor matches from HistoryUrlProvider in CullPoorMatches function.
Am I right that all URLs not qualifying for this criterias will not be shown in omnibox, no matter what the user input is?
How such criterias were chosen and may we reconsider them? What are the main limits? Speed of autocomplete? Or memory usage?
What about idea of changing autocomplete to use HQP only, removing HistoryURLProvider? Is there a task for this? Is it still active? I could not find it, only some remarks in other tasks.
WBR, Alexander Yashkin.
Peter Kasting
Feb 1, 2017, 3:47:51 PM2/1/17
to Alexander Yashkin, Chrome Omnibox Team
On Wed, Feb 1, 2017 at 5:14 AM, Alexander Yashkin <a-...@yandex-team.ru> wrote:
Am I right that all URLs not qualifying for this criterias will not be shown in omnibox, no matter what the user input is?
Navsuggest could show other URLs, including ones you haven't visited, but the relevance of NavSuggest is low. Similarly ZeroSuggest can do so, but kicks in in limited situations.
Other than that, I think you are correct.
How such criterias were chosen and may we reconsider them?
mpearson can probably speak to that better.
What are the main limits? Speed of autocomplete? Or memory usage?
Both are critically important. The third factor is simply ranking quality. If we want to include more matches, and we can do it within those other limits, the question is then whether our ranking algorithm will actually make this a net improvement for users, or if we need to fix "crowding out" problems.
What about idea of changing autocomplete to use HQP only, removing HistoryURLProvider? Is there a task for this? Is it still active? I could not find it, only some remarks in other tasks.
I'd like to see it happen, but it would be tricky to do. First step would be to tackle https://bugs.chromium.org/p/chromium/issues/detail?id=279386 .
PK
Mark Pearson
Feb 1, 2017, 4:56:29 PM2/1/17
to Alexander Yashkin, Peter Kasting
Some corrections below, but leaving chromium-dev as BCC.
On Wed, Feb 1, 2017 at 5:14 AM, Alexander Yashkin <a-...@yandex-team.ru> wrote:Am I right that all URLs not qualifying for this criterias will not be shown in omnibox, no matter what the user input is?Navsuggest could show other URLs, including ones you haven't visited, but the relevance of NavSuggest is low. Similarly ZeroSuggest can do so, but kicks in in limited situations.
I'll add to the above:
The bookmarks provider can also show URLs that do not meet the criteria.
Zero suggest (suggestions on focus) kicks in a lot on Android, and in these cases it can suggest never-visited URLs.
Physical web beacons (low energy internet of things beacons transmitted by devices near you) can also cause suggestions of URLs that don't meet the criteria. Running canary and dev field trials on mobile platforms at the moment.
If you have a URL in your clipboard, it can also be suggested (iOS only at the moment).
chrome:// URLs can also be suggested and don't meet the criteria.
It's also possible that the URL providers suggest a URL that's a prefix of one you typed even if it doesn't meet the criteria. For example, suggesting www.example.com/ if you've visited www.example.com/blah
There might be more possibilities too. In short, the limitation you found only applies to only two sources of suggestions (HistoryURL provider and HistoryQuick provider), and even those providers have exceptions.
How such criterias were chosen and may we reconsider them?mpearson can probably speak to that better.
Honestly, we haven't given this setting much thought. It was basically an intuitive guess about the kinds of previously-visited URLs people are likely to want to retrieve using the omnibox (recent OR visited frequently OR retrieved previously). The main negative of increasing the set of URLs considered is performance. It takes time to search the set of candidate URLs. Currently this search is the slowest part of the omnibox system. Peter Kasting also mentions the other two considerations below.
--mark
What are the main limits? Speed of autocomplete? Or memory usage?Both are critically important. The third factor is simply ranking quality. If we want to include more matches, and we can do it within those other limits, the question is then whether our ranking algorithm will actually make this a net improvement for users, or if we need to fix "crowding out" problems.What about idea of changing autocomplete to use HQP only, removing HistoryURLProvider? Is there a task for this? Is it still active? I could not find it, only some remarks in other tasks.I'd like to see it happen, but it would be tricky to do. First step would be to tackle https://bugs.chromium.org/p/chromium/issues/detail?id=279386 .PK
--
You received this message because you are subscribed to the Google Groups "Omnibox Team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-omnibox-team+unsubscribe...@google.com.
To post to this group, send email to chrome-om...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/chrome-omnibox-team/CAAHOzFAAvBzsMH0xntigrq3b5Gn6CMnGJAN23vX4iyvCEkOVfg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages