New issue
Advanced search Search tips
Starred by 12 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2011
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 99131: Display UNKNOWN navigation results with more than a bare hostname

Reported by pkasting@chromium.org, Oct 5 2011 Project Member

Issue description

The HUP currently avoids displaying what-you-typed results for UNKNOWN inputs in most cases.  We should relax that and go ahead and show these navigational results (not as defaults, though) if the input has more than a bare hostname -- i.e. if there's a username, password, port, path, query, or ref.

Food for thought: perhaps if there are at least two of these components, navigating should be the default, as an intranet URL in that case is probably much more likely than a search.
 

Comment 1 by pkasting@chromium.org, Oct 5 2011

Labels: Mstone-15
I think I should do both parts above and do them for M15.

Comment 2 by pkasting@chromium.org, Oct 5 2011

Labels: ReleaseBlock-Stable

Comment 3 by kareng@google.com, Oct 10 2011

ping only one more week for m15.

Comment 4 by pkasting@chromium.org, Oct 13 2011

 Issue 99827  has been merged into this issue.

Comment 5 by dhsharp@google.com, Oct 13 2011

Suggestion: a hostname that has dots in it should count as a point in your "at least two" scheme for navigating instead of searching. eg, foo.bar/baz is most likely intended to be a navigation to an intranet URL.

Comment 6 by pkasting@chromium.org, Oct 13 2011

This would make anything with dots ("browser.urlbar.autofill") give you the option to navigate (distracting) and wouldn't be good for e.g. math ("4.5/3").

In principle I don't think "unknown TLD with dots" is dramatically more or less likely than "unknown TLD without dots" to represent an intranet host.

I'm pretty sure that the fix I'm going to land here, combined with the fix for  issue 94806 , should make life inside Google dramatically better :)

Comment 7 by pkasting@chromium.org, Oct 13 2011

Labels: Merge-Requested
Fixed on trunk in r105363.  Holding open for M15 merge request.

Comment 8 by bugdroid1@chromium.org, Oct 13 2011

Project Member
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=105363

------------------------------------------------------------------------
r105363 | pkasting@chromium.org | Thu Oct 13 13:37:25 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete_unittest.cc?r1=105363&r2=105362&pathrev=105363
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete.h?r1=105363&r2=105362&pathrev=105363
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/history_url_provider.cc?r1=105363&r2=105362&pathrev=105363
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/history_url_provider_unittest.cc?r1=105363&r2=105362&pathrev=105363
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete.cc?r1=105363&r2=105362&pathrev=105363

Tweak omnibox parsing heuristics more:
* UNKNOWN inputs with at least one non-host component get displayed as "possible navigations" (by setting |have_what_you_typed_match| true in HistoryURLProvider::DoAutocomplete()).
* Inputs with at least two non-host components (generally) get treated as URLs by AutocompleteInput::Parse().  Technically these could be searches but intranet URLs are much more likely.
* Allow more cases to be REQUESTED_URL, such as "user@host" + ctrl.  I'm not sure these were ever intentionally excluded from the ctrl-enter handling, and I don't see why they should be.

Also use url_parse::ParsePort(), which didn't use to exist (I think?) to replace some code in AutocompleteInput::Parse().

BUG= 99131 
TEST=Covered by unittests
Review URL: http://codereview.chromium.org/8258004
------------------------------------------------------------------------

Comment 9 by kareng@google.com, Oct 13 2011

ok we'll keep an eye on it on canary tomorrow and take it from there.

Comment 10 by kareng@google.com, Oct 14 2011

Peter, today's windows canary will be late but you can confirm this against mac canary to make sure it's behaving as expected. it's 16.0.908.0.

Comment 11 by kareng@google.com, Oct 17 2011

Labels: -Merge-Requested Merge-Approved

Comment 12 by bugdroid1@chromium.org, Oct 17 2011

Project Member
Labels: -merge-approved merge-merged-874
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=105880

------------------------------------------------------------------------
r105880 | pkasting@chromium.org | Mon Oct 17 12:23:43 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/874/src/chrome/browser/autocomplete/autocomplete_unittest.cc?r1=105880&r2=105879&pathrev=105880
 M http://src.chromium.org/viewvc/chrome/branches/874/src/chrome/browser/autocomplete/history_url_provider.cc?r1=105880&r2=105879&pathrev=105880
 M http://src.chromium.org/viewvc/chrome/branches/874/src/chrome/browser/autocomplete/autocomplete.h?r1=105880&r2=105879&pathrev=105880
 M http://src.chromium.org/viewvc/chrome/branches/874/src/chrome/browser/autocomplete/history_url_provider_unittest.cc?r1=105880&r2=105879&pathrev=105880
 M http://src.chromium.org/viewvc/chrome/branches/874/src/chrome/browser/autocomplete/autocomplete.cc?r1=105880&r2=105879&pathrev=105880

Merge 105363 - Tweak omnibox parsing heuristics more:
* UNKNOWN inputs with at least one non-host component get displayed as "possible navigations" (by setting |have_what_you_typed_match| true in HistoryURLProvider::DoAutocomplete()).
* Inputs with at least two non-host components (generally) get treated as URLs by AutocompleteInput::Parse().  Technically these could be searches but intranet URLs are much more likely.
* Allow more cases to be REQUESTED_URL, such as "user@host" + ctrl.  I'm not sure these were ever intentionally excluded from the ctrl-enter handling, and I don't see why they should be.

Also use url_parse::ParsePort(), which didn't use to exist (I think?) to replace some code in AutocompleteInput::Parse().

BUG= 99131 
TEST=Covered by unittests
Review URL: http://codereview.chromium.org/8258004

TBR=pkasting@chromium.org
Review URL: http://codereview.chromium.org/8294018
------------------------------------------------------------------------

Comment 13 by pkasting@chromium.org, Oct 17 2011

Status: Fixed

Comment 14 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 15 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-UI -Feature-Omnibox -Mstone-15 Cr-UI Cr-UI-Browser-Omnibox M-15

Comment 16 by bugdroid1@chromium.org, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment