Thanks for the report.

Pages that are bookmarked are given a boost.  Perhaps it's not strong enough for you?  It would help to have some more details about this particular example to know if we need to turn up this knob is general.

Please submit chrome://omnibox output for the input that you hope would show a particular URL that's bookmarked.  Check the "show all details" and "show results per provider" boxes.  Also please submit chrome://omnibox output for an input that does show the URL you want as a suggestion; that'll give us the background information about how much Chrome thinks you visit the page.

thanks,
mark

Thanks for the quick response!
I attached the screenshot for input 'tickaroo' which is the company I work for so you can imagine how many urls with this word in it. usually I bookmark the most important ones thats why I expect them to be the first ones suggested to me when I start typing tik

What I'm suggesting is a little more than a knob value I guess. I mean order the bookmarked results first, show them, order the rest, *append* them to the list

I don't think the second screenshot is helpful here, I just know I have many bookmarked urls with tickaroo and I would love to start with them in the omnibox suggestions :)

Deleted: screenshot-omnibox 2017-02-01 12-06-39.jpeg 942 KB

	screenshot-omnibox 2017-02-01 12-06-39.jpeg 942 KB View Download

this probably need a separate bug, but I would love to hear your input on this:
how can I show more results in the omnibox? even using a flag or a hack!

There are no flags or hacks to do this.  The general response is that cases where people want more results are usually cases where we need to improve our ranking.  However, I think there are also edge cases where you need to choose among a bunch of very similar pages that can't easily be ranked, and we actually _should_ show more results.  I don't recall if that's captured on another bug.

The screenshot is helpful, thanks.  It shows that three bookmarks (git.tickaroo...) are getting retrieved.  They're just not being suggested because other URLs that you visit more often (as well as one popular query "tickaroo live ticker") are outscoring them.

The problem with always putting bookmarks first is that it makes errant matches look awful.  For example, do you want the top suggestion for "ios7" to be a git.tickaroo page?  Or likewise for a query / search for "git tree"?  You have bookmarks (maybe more than one) that match these inputs.

I'm not sure what to tell you.  Hit space and type another word in the omnibox that'll narrow the suggestion list down to the bookmark you want?  I'm not sure how to resolve this in general for such a vague, broad input.  I'll leave it open assigned to me to think more about.

yeah you are right it's not as simple as I thought it is.
I just wish I can show more results (or all!)
 

This is the sort of task that the ShortcutsProvider was supposed to solve: if inputs like "tickaroo" are the start of input strings that eventually lead to these URLs, then we should learn and reinforce that, so that we start suggesting them aggressively as the user starts typing those specific inputs.

I think the ShortcutsProvider not working very well and not being scored aggressively enough is the primary problem here, and changing bookmark weighting should be considered more for the case of "surface this URL at all to bootstrap the shortcuts system".

Reading over this bug and seeing the scoring and visit counts of the URLs that are beating the desired bookmarked URL, I don't see what to do.  There's no way I can turn up the base bookmark suggestion score to beat those results without having a ton of downsides (errant matches), as I said in comment #8.

I think pkasting's comments in comment #10 are a little misdirected.  Shortcuts provider can only help if the suggestion gets shown in the dropdown; in this case, it's difficult to make these bookmarked suggestions get shown in short, natural inputs.

I'm going to leave this bug as available, though with no clear idea on what to do.

The idea of the shortcuts provider is that if you type "long string that matches a bookmark" -- i.e. if you show the result at all, even with an "unnatural" input -- we start scoring for prefixes of that input as well, so "long" would begin matching that bookmark (but at a lower score).  This helps address the bootstrapping issue, because if the user then starts choosing this result on shorter strings, they become very high-scoring for that result.

Replacing Hotlist=Reassess-2018 label with NextAction=01/09/2018 per omnibox bug triage doc.

actually remove the obsolete label

The NextAction date has arrived: 2018-01-09

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

The NextAction date has arrived: 2019-01-08