I totally agree. The omnibar does a good job but it could do so much better by
adapting to the user's usage patterns.

It seems to me it already does adapt to the user's usage patterns but it doesn't seem 
as efficient as how it is in Firefox - though I cannot explain whatever it is.
Also it would be nice if more results could be displayed - either by making the drop 
down longer or by adding a scroll bar like in FireFox. Ideally the user could choose 
his preference.

It should at least sort better, I can really notice that omnibar is not able to find 
the 'history results' I expected.
I know for instance I browse to http://forums.mozillazine.org/viewforum.php?f=23

Firefox leans this and whenever I enter '23' for instance it will give me the above 
link ON TOP! Omnibar doesn't show the link at all, no matter how many times I opened 
the site.

Omnibar results seem to be:
1. Search google for (KEYWORD)
2. Sometimes some domain 'entry points' (stripped down to domain itself)
3. (KEYWORD)/  (this is direct browse to domain, do we need this one at all?)
4. Some bookmarks/history containing (KEYWORD), not correctly sorted at all by 
frequency.
5. One link to history containing (KEYWORD).

Personally I would just like: 
0. No selection from list = search with search engine (default google).
1. Some (6?) links containing (KEYWORD) in URL/cache/title, sorted by frequency 
visited.
2+ rest isn't required for me, but some may like some of current options like: 3, 5

I think omnibar needs more attention to make it really usefull.

I think this is actually by design... but I agree that it is _wrong_. The awesomebar
really does an awesome job in this regard.

For Keywords and domain names we don't really need this at all, it's page titles and
url path which really make this interesting (looking for a news item or bugzilla bug
for example).

Ah, I would also like to add it might be a good idea to be able to scroll through the 
results of the omnibar with the mouse wheel scroll.

Also, here's an example of a problem I have with the omnibar not remembering a 
webpage I visit often :
http://en.wikipedia.org/wiki/Wikipedia:Reference_desk/Mathematics
When searching the omnibar for "reference" or "mathematics", it does not appear at 
all, while in FireFox it appears first for both searches.

Marking this as a feature request and cc'ing pkasting on it. He'll be able to provide 
more information about design decisions.

There are far too many disparate requests in the comments on this bug.  Please keep 
bugs to one issue.

I believe most of what's being requested here is some form of machine learning that 
will match input strings to result URLs.  The Awesome Bar does this, the Omnibox does 
not.  This is worth investigation, we've talked about it off and on for a good year 
or so.

There are other issues above:
* We do, actually, sort by visit frequency -- or more specifically typed frequency 
(since the Omnibox is an accelerator for typing) and then visit frequency.
* Displaying more results has tradeoffs.  We may end up experimenting here.  There 
are a lot of subtle issues.
* Wheel scroll through results only makes sense if we actually have a scrollbar, 
which we don't right now.  If we did, then we would certainly want to support 
something like this.
* Poor matching inside URL components is an artifact of how we're doing the queries 
to locate these matches.  We've traded accuracy and depth away for speed here.  Long 
tem I'd like to find a solution that lets us get better results, on the level of the 
Awesome Bar, but in the short term it has not been clear how to achieve that 
_quickly_.  Speed is a guiding design principle of the Omnibox.

Just to add another case when this (poor matching inside URL components) is annoying 
- I like to look once in a while at what new issues appear on http://code.google.com/p/chromium/issues/, so I type "chromium issues", but the above 
address is never displayed, links to individual issues appear instead (since they 
have "issue" and "chromium" in title)

I notice this most on search.  I'd like to be able to type g-Tab and search google,
but what actually happens is that it loads github, because I went there a couple
times for the scriptaculous wiki.  The same thing happens for wikipedia, where I'd
like to type w-Tab and get to wikipedia search, but instead I get some
weblogs.mozillazine.org page about tracemonkey.  This is despite the fact that I go
to google and wikipedia very often, and the other sites were visited only a time or
two.  If omnibox were using either use frequency or even most recently visited, I'd
be getting much better results.  It may be that since I'm using the search feature
instead of directly going to the page, I'm not increasing the visit frequency, but I
should be.

comment 9 is not about this bug at all.  This problem is occuring because you've 
typed in those "bad" pages more than you've typed in google or wikipedia.  One fix is 
to simply manually visit google or wikipedia more.  Another fix is to disconnect the 
engine used for type-to-search from inline autocompletion.  There are tricky 
ramifications there.

Except that I specifically said I had NOT typed in those pages more often.  I typed
each in once. (and probably reloaded once or twice because I have the browser set to
restore the session)  I went to google and wikipedia many times using the omnibar,
unless you don't count using the search feature in the omnibar as visiting the site
manually, which you should since it happens in the omnibar.  It seemed to be simply
sorting alphabetically and never improving.

I was trying to make clear that visiting a Google search result page does not count 
as typing in the address of the front page of Google, but apparently I failed.  So I 
reiterate that here.  Inline autocompletion was designed to help you type in pages 
you're trying to navigate to.  Tab-to-search is not navigating to the Google 
frontpage and accordingly does not boost its typed count.

Gah, that last post was (obviously) by me

Firefox does a really good job here. There might be a small performance penalty but I 
think it will really improve the omnibar if we copied (more) functionality from the 
awesomebar. The Firefox team also noticed that the awesomebar is somewhat slower but 
they found the perfect solution: displaying the found results for the awesomebar 
incrementally to the dropdown list.

My personal opinion: copy the awesomebar as closely as possible. Why reinvent the 
wheel while we all agree that the awesomebar is just.... awesome
(for a small trade-off: slightly lower performance).

I've created an issue (2191) which appears to be a duplicate of this issue, but I 
think the example that is provided there illustrates well why this behavior is 
obviously a misfeature.

I prefer omnibar show the root url first, so before it show the other urls.

I do not agree with comment 16.
What I would like is the following.

Remove all "search google for ...." and root urls from search results dropdown.
If the url bar itself contains a valid url and a user presses enter: browse to the url.
If the url bar does not contain a valid url and the user presses enter: open google's
or other search engine's site with the search criteria given.

In all (even above two) cases: try to match the url bar content to URL's and page
titles of history and bookmarks and display all results, ordered by visit frequency,
in the dropdown of the url bar.

Above description is what firefox does.

Sorry but how can this be status unconfirmed?
I see lots of people agreeing here, even from people of chromium itself?

Please revert the status!

@pkasting
you could be here all day long explaining how the omnibar was designed for speed but 
it doesn't change the fact that omnibar results are mostly useless, an old tyre 
company slogan explains the issue very well, "speed without handling is useless" (or 
something like that). Firefox resolved the speed problem showing results 
incrementally and replacing the favicon with a throbber while it is querying the 
database, but normally the desired result is the first that appears, so it isn't slow  
at all

"Power is nothing without control" :)

 Issue 7295  has been merged into this issue.

We could use the data on how long the person stayed on the site suggested.

Example problem:
I have visited fahrplan.zvv.ch and fahrplan.sbb.ch before. Now, when I want 
to get to fahrplan.sbb.ch, I start typing "fa": fahrplan.zvv.ch is the 
first suggestion, while fahplan.sbb.ch is the sixth. As I just glimpse at 
the URL bar, full with fahrplan.zvv.ch, I tap Enter right away - and a 
second after I realize that it is zvv, while I wanted sbb; I press Ctrl-L, 
type "fah", and carefully select fahrplan.sbb.ch from the list.
It repeats every single time - I almost never need fahrplan.zvv.ch, while I 
use fahrplan.sbb.ch multiple times a day. Though, the wrong sorting 
persists.

If Chrome noticed that I spend only very short time on the first 
suggestion, and switch to another suggestion soon, and resorted the items 
accordingly - it would help.

 Issue 3082  has been merged into this issue.

I agree, with the recommendation to activate some learning. I think you could 
leverage not only from firefox awesomebar which does a perfect job, but also from 
launchy and farr projects which also have some learning built-in.

Frankly I just don't get why it has to be slow... as the history page comes pretty 
fast... I mean if the delay is about retreiving favicons and such I would just not 
retrieve them, and besides I could keep a ranking of the most visited urls updated 
very often while the user is reading... isn't chrome multi process? Or how about 
storing the urls in some type of tree. 

Sorry if I am oversimplifying..

I agree 100% [and more] with g.teunis. I've recently switched from using Firefox to 
Chrome as my default browser. The relatively inferiority of the Omnibox to the Awesome 
Bar is the only big problem with Chrome. It needs to learn from History better! 
Otherwise it's truly great.

I also agree, the awesome bar works much better finding most visited web pages, it 
would be also interesting that the omnibar could display this result (the most visited 
or relevant) directly into the bar, allowing to do a simple enter if the web page is 
what I am searching.

Area-UI-Features label replaces Area-BrowserUI label

Not sure if it is related to the issues discussed in this topic, but what I miss the
most from Firefox awesomebar is that it matches what you are typing not only at the
beginning of the history urls, but also in the middle and even in page titles. 

What I mean is if you have visited this url:

`http://subdomain.example.com/?p=page (Title: Awesome Site)`

The only way Chrome could find it is if you start typing from the beginning
("subdomain..."), while Firefox will find it if you type "example", "page" or even
"awesome". It is very convenient for forums and discussion boards because they
usually have hard to remember urls with useful info only in their titles (like this
page for example).

Please don't comment randomly about other issues in particular bugs.  This is about 
machine learning, not what mtches can be made at all.

Besides, Chrome can, in fact, match parts of the URL, page title, or page content.  These 
matches are not ranked very highly, but that is a different issue.

@pkastings: then re-split the bug again, I don't get it: first you (google) join the 
bugs and then you kind of reject feedback from one of the originating bugs. 

I am a web developer and all my sites start with "localhost" and I hate to just have 
to type localhost, play with shift-arrow keys, etc to type the exact website folder 
after localhost. And the same for a lot of other pages that go inside a given domain. 
I just user firefox for development. I love the speed of chrome but I end up using it 
just for fast, casual browsing, not serious work. Sorry to tell, but truth is far 
better than soft lies.

What on Earth are you talking about with "join the bugs"?  There is no "Chrome cannot 
match page titles" bug that has been "merged" with this one.

gramhorst, please see  Issue 19736 

Sorry to have caused any confusion on the team. My apologies. Feel free to remove my 
entry and this one if apropriate.

Almost 1.5 years later and still nothing..
This is one of the most essential parts of the browser and you guys prefer speed over
usability/results? I rather wait 1 more second than spend 10 seconds more manually
typing the url or searching for the right one.
And really, with almost a year of history in my Firefox awesomebar, it's still
instant.. The awesomebar IS just awesome, just copy their thing and go from there.

I think a good trade off of speed vs usability is if you just add querying the page 
title. no deep querying necessary. Most often the keywords the user remembers are a 
part of the url or a part of the title. can't see the big speed penalty of searching 
page titles, they are usualy quite short strings of text...

We already query page titles, as has been said multiple times above.  Please refrain 
from suggesting solutions unless you understand the full problem space here (which is 
probably only true for about four people, all of whom are Chromium developers).

I visited the web https://chrome.google.com/extensions.
Now I typing in the omnibox the word "extensions", the omnibox suggest me to search in 
google the word extensions, but I don't see anywhere the webpage that i just visited 
few seconds ago.
The omnibox should match the keyword in the wole url, not just in the domain.

Thanks for your time and patience.

 Issue 44571  has been merged into this issue.

Just noticed, thanks to your merging, that most of the comment on this page should be on  Issue 19736  
(http://code.google.com/p/chromium/issues/detail?id=19736), since this page is about 
machine learning (ordering results) and the other is about substring matching (search anywhere in URL and 
Title). 
Not sure if this helps in any way, maybe somebody could move the comments around; just saying.

My issue was indeed about both.
edit:link

A bug in the bug :P

The "What is the expected result" and "What happens instead" seem to have switched answers on the top as of 12th February 2011.

Also is this the right bug to knock on for suggestion of bookmarked URLs in the omnibox (it currently doesn't pull them up with any efficiency) or should I head over to 60107, 19736 or some other?

Thanks :)

 Bug 19736  is the bug for that and it is a WIP right now.

If I could make a suggestion without creating a new feature request: when typing keywords into Chrome's Omnibox I think it should make use of our bookmark's titles. I often find myself searching for a site I've already visited in the past and remember that I've bookmarked it. With tons of bookmarks stored in my profile I wish Chrome would search for those first (using tags as well, that are supposed to be supported in the future), like Firefox does. It could display your bookmarks finds first, then history search results and then search engine's suggestions.

What do you think about this guys?

@50, that's not this bug.  Please don't hijack this bug to talk about it.

(Besides, we already match against bookmark titles, we just don't yet rank the matches highly.)

Google Reader is by far (x100) my most visited site.

When I used Firefox, just typing R and enter would get me to Google Reader. With Chrome, I have to type "reader", hit down and then hit enter.

Also, I check AAPL stock every day with Google Finance.

How come typing AAPL in omnibox doesn't give me a link to Google Finance's AAPL page? Instead, the first URL result is Yahoo Finance. grrr

It is in since M14, but behind about:flags

It's also not persistent yet, and it can't yet do inline autocompletion :)

Triaging bugs that were assigned to georgey@

I'm closing this bug.

There are a huge variety of issues that have been posted here, and a number of those are valid and still open.  However, the core issue this bug was about has been addressed: Chrome has an on-by-default omnibox provider called the ShortcutsProvider that matches input strings to output URLs.

There are still a number of issues with the ShortcutsProvider.  Its ranking could be much better.  It sometimes "learns" invalid URLs and suggests them later.  It can't inline autocomplete.  All of these are covered by other open bugs.

There are also a variety of other topics covered above.  For example, we've discovered that bundled apps can interfere with Chrome learning certain URLs like Google Calendar or Reader.  The ranking from some of our other omnibox providers could be improved.  Etc.  These are also covered under other bugs and generally have been fixed.  One noteworthy change is that in Chrome 29+, more omnibox results will be ranked using a "frecency" algorithm that resembles Firefox'.