User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170316213829 Steps to reproduce: 1. Open new tab 2. In address bar paste 729/MON string 3. hit enter Actual results: Firefox try load page from adres http://0.0.2.217/MON Expected results: Redirect to google page and search entered phrase.
You can use the search bar or search keywords. It does not work in older Firefox too, will try to find the server "729" and fail.
Has STR: --- → yes
Component: Untriaged → Location Bar
For our code that string looks like a url, and indeed it could be. Looks like a case similar to Bug 1302004, but in that case the string was fully numeric. While we could potentially exclude IPs like 0.x.x.x, something like "123456789/mon" would still generate a valid ip. As a side note, Chrome suggests a search as the first entry, and the converted ip as the second one. If instead I type something that effectively looks like an ip, it is the first entry. It also never suggests invalid urls in the 0.x.x.x range. I suspect that would be the right thing to do.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Valentin, can we make the URI constructor just break or not 'fix' these links? That would automatically fix this. Otherwise, we'll have to update the uri fixup service, I guess.
(In reply to :Gijs from comment #3) > Valentin, can we make the URI constructor just break or not 'fix' these > links? That would automatically fix this. Otherwise, we'll have to update > the uri fixup service, I guess. What the URI constructor will get is http://729/MON - this is a valid URI, and is normalized to http://0.0.2.217/MON I don't know how we can differentiate in the URI code between stuff we want to normalize, and stuff we don't. Such logic should probably go into the url-bar or the uri fixup code.
You need to log in before you can comment on or make changes to this bug.