When users navigate to an intranet host that has not been previously typed, treat it as a typed navigation.

This fixes two different problems:
(1) Due to scheme-stripping, a user who navigated to e.g. "host/path" via a link or bookmark, for a not-previously-typed host, would erroneously get a search page instead of a navigation when reloading via hitting enter or when editing the path to be something else.  We could instead fix this by being more conservative about scheme-stripping, but that is uglier UI, a bigger change, and doesn't solve problem (2).
(2) Users who navigated to intranet hosts (with or without a path or other URL components) via link clicks/bookmarks/etc. would later try to type them and be frustrated that the omnibox would do a search and then show the accidental search infobar.  This change makes the omnibox more aggressive about learning that such hostnames are valid intranet hosts even before users type them, if they've at least visited them.

There are four issues here:
(1) Because in incognito mode we never add navigations to any history DBs, users there won't see the above benefits.  In fact, users there will struggle to use (new) intranet hosts in general.  I filed bug 100271 about this.
(2) The omnibox will now be more likely to inline-autocomplete intranet URLs you haven't actually typed before.  After thinking for a while I don't think this will have a large effect either way especially as intranet URLs are often short (and thus it's less likely users will try to search or navigate to a pure prefix of one).
(3) Heavy intranet users will have a larger in-memory DB.  I don't think this effect will be dramatic since it's just one URL per unique hostname, and there's no real way around this anyway.
(4) The additional checking in AddPage() could make navigation slower.  I don't think this ought to happen because most navigations will fail the RCDS check for "no known TLD" (which ought to be fast, as that code is called by things like cookie management), so they'll never even check the database.  If this turns out to be wrong, then we'll need to fall back on something like the solution in bug 100271.

BUG=94806
TEST=On a clean profile, add a bookmark for some intranet host (without navigating there), with or without a path.  Click on the bookmark.  Then try to modify the path and check that the omnibox still wants to navigate, not search.
Review URL: http://codereview.chromium.org/8286011

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@105565 0039d316-1c4b-4281-b951-d872f2087c98
5 files changed