Here are chrome://omnibox results for these queries (with Show incomplete results + Show all details)

Deleted: ger.html 18.9 KB

ger.html 18.9 KB View Download

Deleted: gerrit.html 19.7 KB

gerrit.html 19.7 KB View Download

Deleted: gerrit chromium.html 17.0 KB

gerrit chromium.html 17.0 KB View Download

Deleted: gerrit code review chromium.html 15.6 KB

gerrit code review chromium.html 15.6 KB View Download

Deleted: gerrit code review (chromium).html 10.6 KB

gerrit code review (chromium).html 10.6 KB View Download

I don't understand.  The output files you provided clearly show the desired URL ( https://chromium-review.googlesource.com/q/status:open ) is in the middle of the dropdown for all those inputs, "ger", "gerrit", etc., just with the title "status:open · Gerrit Code Review".  It's even number two on "gerrit code review chromium", which is as high as can be expected because it cannot be shown at number one (as a suggestion within the omnibox) because the URL is not an extension of the omnibox input text.

Is your complaint that the omnibox is selecting the actual title of the page instead of the title you gave to the bookmark?

FWIW, if that's the problem, I do think we should check whether URLs are bookmarked, and if so show the star icon and the bookmark title in place of the page title.  The case where the titles will differ is one where the bookmark title represents a user's manual entry, and is thus presumably a more relevant (to that user) way of describing the page.

We do get the starred status right, just not the title.

I think using the bookmark title always is *probably* right, but I'm not positive.  I certainly know of people who intentionally give pages short titles (e.g., "gg" for "Google Groups") in order to fit more bookmarks on the bookmark bar.  I imagine they mostly remember these bookmarks by their location on the bookmark bar, not by their title, which means showing the title when we're suggesting a URL in the omnibox from history based on its history (and not its bookmark status/bookmark title), might be better.

But let's wait for lgarron@ to make sure we've diagnosed the issue right before we talk too much about solutions...

It seems my results have changed again, so "gerrit chromium" and "gerrit code review chromium" actually show the right result.

I don't see it for "ger" and "gerrit", though.

Showing the bookmark title if I have the URL bookmarked definitely matches what I would expect, since I often change generic page titles into something containing more relevant keywords.
But then, I know how to (ab)use the search engine functionality to force deterministic navigation for keywords/abbreviations.

Deleted: Screen Shot 2017-04-12 at 11.12.42.png 152 KB

	Screen Shot 2017-04-12 at 11.12.42.png 152 KB View Download

Deleted: Screen Shot 2017-04-12 at 11.13.10.png 180 KB

	Screen Shot 2017-04-12 at 11.13.10.png 180 KB View Download

Deleted: Screen Shot 2017-04-12 at 11.14.05.png 181 KB

	Screen Shot 2017-04-12 at 11.14.05.png 181 KB View Download

chrome://omnibox information would help again to see if there's a ranking issue.  In general it seems you're typing popular words in which you have visited many pages with those words multiple times, so it's hard to know which to show in the dropdown.  The statistics provided by chrome://omnibox would help.  It's not even like the URL you want is the only bookmarked page that matches those words...

I guess that's fair.

All I know is that I'm frequently typing exact words from that same bookmark when I want to open it, and Chrome is not being helpful. ¯\_(ツ)_/¯

This is a contrast with another tool I use – Quicksilver (https://qsapp.com/) – which makes it really easy to select the right thing even if there are more than 5-10 close matches (there's a full list of matches below the fold), and easy to retrain quickly (it will learn even if you selected something below the fold, and you there are a few manual re-prioritization mechanisms).

Regarding re-training and remembering associations between "user entered this text" and "user wanted this suggestion", there's a part of the omnibox system called "shortcuts."  It's meant to handle this.  Unfortunately, it does it rather poorly.  *sigh*  See bug 252032 and bug 341532.  I haven't invested much time in improving it because there are bigger problems (in my opinion) that make it difficult for users to revisit pages they say recently.  (The pages aren't appearing / being ranked strongly enough.  Shortcuts can only help if pages at least appear strongly enough that the association can be learned.)

I'm going to morph this bug to the particular request about bookmark titles.

> I haven't invested much time in improving it because there are bigger problems (in my > opinion) that make it difficult for users to revisit pages they say recently.
> ...
> I'm going to morph this bug to the particular request about bookmark titles.

Sounds good. Thanks for the diligence!

I looked into how to do this.  It's fairly straightforward.

We'd need to add something to BookmarkModel to get the BookmarkNode(s) associate with a given URL.  (The only feature BookmarkModel has right now involves searching, which is a bad idea, when a lookup is possible and faster.)

Then we'd probably want to model ScoredHistoryMatch
https://cs.chromium.org/chromium/src/components/omnibox/browser/url_index_private_data.cc?type=cs&l=711-715
to pass in the title of the bookmarked URL in the |hist_item| URLRow parameter.  (Just override the default title.)

If the URL is bookmarked multiples times, just pick one arbitrarily.

This logic might have to be duplicated in other providers such as HistoryURL and Shortcuts and maybe ZeroSuggest and maybe Search (for navsuggest).

Taking this, as I figured out how to do it (per comment #11).

Punting this, as I don't my solution in comment #11 is the right answer.

Instead, I think AutocompleteResult, as it gathers results from providers, should look up whether a URL is bookmarked and, if so, replace its title (description) with the bookmark title, highlighted appropriately.  It's best if this logic lives in one place rather than have each provider that could return a URL have to connect to the bookmark system and make this substitution.

CC pkasting for his thoughts / objections

Hmmmm.

I'm inclined to say your comment 11 idea was a better answer, and we should simply place the code in a common location and call it from the providers that want to use it.

Doing this from AutocompleteResult feels like a layering violation.  Consider for example the following hypothetical case:

* The user bookmarks garydanko.com and keeps the default title ("Restaurant Gary Danko").
* The user starts to type something like "SF Gary Da" and gets a highly-ranked navsuggestion for garydanko.com from the search provider.  The server provides some kind of useful alternate title ("Gary Danko San Francisco - Main Site") based specifically on the user's input.

This seems like a case where we would want to let the server's judgment, as filtered through the SearchProvider, govern.  Does the SearchProvider know for sure whether the server or the local title is better?  Maybe not, but it's at least in a better position to know than AutocompleteResult.

So I think while we need not copy-and-paste code, we should have the functionality itself happen in the individual providers.  That's the appropriate place to be making the decision of "what should a match title be".

> This seems like a case where we would want to let the server's judgment,
> as filtered through the SearchProvider, govern.  Does the SearchProvider
> know for sure whether the server or the local title is better? 
> Maybe not, but it's at least in a better position to know
> than AutocompleteResult.
>
> That's the appropriate place to be making the decision of
> "what should a match title be".

I don't think so.  I don't think each provider should be making this decision.  That's what we had before implicitly.  HQP would say, I'm very confident that result X is relevant and should have title Y.  Bookmark provider would say, I'm somewhat confidence result X is relevant and should have title Z.  Then AutocompleteResult would say, ah, I believe HQP more, so we're using title Y.

The point of this bug, as I took the user to say, is that if the user bothered to bookmark a result, then we should use the bookmarked title.  Period.  It doesn't matter why we're returning a result.  The user will recognize their bookmarked title, and that's more important than whatever any component of the system would say.  Don't overrule the user.

If you want each provider to vote and make its own decisions about titles, then we can probably close this as WontFix (working as intended).  I'm not sure that's the right answer.

It's not working as intended.  The HQP is just wrong.  The title from the history system is not the correct title it should be assigning.

This is because the whole existence of the BookmarkProvider is an implementation detail; we wanted the HQP to search bookmark titles, but doing it this way was easier to accomplish.

All that said, let's say we take as a given that we always want bookmarked results to have bookmark titles.  My point was that AutocompleteResult is the wrong place to enforce this, because really it shouldn't be mucking with titles at all; that's not the layer it should operate at.  The right way to do this would be to enforce that all providers run through this code.

In any case, this is most certainly not WontFix.  The behavior today is broken.

WHile I still think the comment 11 idea is easiest, Mark asked me to post another musing that I had, which is that this sort of fixup would happen in AutocompleteProvider (the base class) as some kind of on-by-default post-pass before results were collected by AutocompleteResult, that providers could opt out of.

I think this overthinks things a bit, but there it is for posterity.

In any case... after thinking about this a bit more, I would probably enable this for HUP/HQP and explicitly not enable it for Shortcuts, ZeroSuggest, or Search.  I think it would better for those to not be doing this fixup.  I might be wrong.  But that's also influencing why I think this is a per-provider decision: because I would actually make the decision differently in the different providers.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot