New issue
Advanced search Search tips

Issue 713789 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Improper handling of non URLs bad padtterns/regex

Reported by wmlthoms...@gmail.com, Apr 20 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.19 Safari/537.36

Steps to reproduce the problem:
If I go to search for say a file.java, or I type in something and it ends with a /. Rather than initiating a search via Google, etc. It appends a http:// and tries to go to that non existent page based on a bad url pattern.

It should not try to go to anything that is not a valid domain suffix. Which .java is a known file type, thus should not try to go to a page if a URL pattern ends in .java, etc.

If I typed in something that started with a URL that is one thing. But if I am looking for a file. It does not handle this properly. Or if I am looking for a missing web page, if the pattern has / on the end. It tries to go there rather than do a search. I can type/paste the same thing into Google search and it does the correct thing. It is how these patterns are handled when typed into the URL portion of the browser.

What is the expected behavior?

What went wrong?
It tries bring up a page for an invalid URL. Rather than initiating a search using the invalid URL pattern as intended.

Did this work before? N/A 

Chrome version: 58.0.3029.19  Channel: dev
OS Version: Gentoo
Flash Version: Shockwave Flash 25.0 r0
 
shot-2017-04-20_13-52-58.jpg
78.0 KB View Download
shot-2017-04-20_13-53-15.jpg
82.6 KB View Download

Comment 1 by mmenke@chromium.org, Apr 20 2017

Components: -UI UI>Browser>Omnibox
For better or for worse, "java" is now a top level domain, so "http://foo.java/" could be a real URL.  As a result, this is probably expected behavior.  Using quotes gets around this behavior.
That was pretty obvious error on my behalf, but the other still stands. I recall this happening with others. If I come across further patterns, that are not valid top level domain suffixes. I will comment.

Comment 3 by mmenke@chromium.org, Apr 20 2017

Status: WontFix (was: Unconfirmed)
Please do.  I'm going to go ahead and close this, just so it's not on our radar, but if you encounter such a case, please do file a new bug.  Chrome's list of registry-controlled domains is at https://chromium.googlesource.com/chromium/src/+/master/net/base/registry_controlled_domains/effective_tld_names.dat (That one will often be more recent than the list that Chrome stable is using internally, of course).

Sign in to add a comment