Any local intranet URL that is invalid, either if the machine does not exist, or the machine does exist, but the specified port has no HTTP server on it, with cause Moz to spawn a search with the machine name as the keyword. Moz 0.9.3 2001080110, always reproducible

iirc Not a bug, this can be changed through preferences.

How is that done ?

In your preferences, go to Navigator: Smart Browsing, and turn Internet Keywords off. I think this should do it.

not a bug ! marking invalid (please reopen if you disagree)

But thats useful - I don't want to turn that off! Just because I may from time to time connect to servers which are not running, I don't feel I should have to lose the internet keyword functionality. Surely you can just check for something that starts with "http://" (etc) and always treat that as a URL - that would be fine since myServer could be a keyword but http://myServer definately isn't

I concur with the reporter. http://foo/ and http://foo:8080/ are valid URIs and should be treated as such. There is no reason to serarch here if we don't search for http://www.adfjkgfbalkdgfdag.com/ A simple "Host not found" would suffice, just as you would get for any other non-existant host. Confirming, but marking as an enchancement.

reassign url bar bugs to new owner..

Joe was dying to have these bugs. Who am I to say no?

This was fixed for links to http://mozilla/ in bug 34943. It's still broken for typing http://mozilla/ into the location bar.

*** Bug 147119 has been marked as a duplicate of this bug. ***

*** Bug 150025 has been marked as a duplicate of this bug. ***

*** Bug 164802 has been marked as a duplicate of this bug. ***

dupe of bug 66183?

*** Bug 178123 has been marked as a duplicate of this bug. ***

At a minimum, I think "localhost" and "http://localhost" should be excluded. It is common practice to redirect ad servers to 127.0.0.1 via the hosts file, even if one is not running a web server. "I feel lucky" resulted in http://www.localhost.net.au/ ( Bug 178123 ). I agree that I shouldn't be forced to completely disable internet keywords just for that.

Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5. I'm not sure whether to post this here or in bug #164802, so sorry if I'm wrong. In a local network using a proxy I can't access machines in the local network (except 'localhost'). I have added the machine's name (e.g. 'mymachine') to the proxy exceptions list and 'ping mymachine' works fine. However, the browser seems not able to resolve 'mymachine' or 'http://mymachine'. This worked fine using px0.4

Forget my last comment. It works (can't tell what's different today, though :( ) Sorry for the spam.

*** Bug 184814 has been marked as a duplicate of this bug. ***

*** Bug 185028 has been marked as a duplicate of this bug. ***

*** Bug 206662 has been marked as a duplicate of this bug. ***

*** Bug 213204 has been marked as a duplicate of this bug. ***

*** Bug 224273 has been marked as a duplicate of this bug. ***

I'm not expert with Bugzilla and can't tell what the actual status of this issue is, but earlier today I linked to (an correct link) of http://localhost:9090/ and was redirected to some strange site about new age internet marketing. I do NOT like this behaviour... in all the other browsers I tested (including Mozilla 1.5b) this just gave me a 404 as I would expect... (I am running Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7)

Place Holder: That's not this bug. That's the firebird "feature" which redirects you to the first google hit if it can't find the URL.

Reagarding the bug vs feature issue. If I type a simple url, that could be consider as a feature, but for complete url like http://mymachine:9999/somedir/somepage.html, I was clearly not searching the web for mymachine, this behavior is illogical and could be very annoying when you are working on develloppement server that are stopped and restarted several time a day. (You have to retype your url because the browser replace it with the one of your search result.) I think the severity of this issue should be upgrade from enhancement to bug.

*** Bug 226971 has been marked as a duplicate of this bug. ***

This should be duped to Bug 184433, since that has a patch.

What if the DNS lookup failed? In this case it is an intranet URL and a keyword search should not occur.

For better or worse, that's the way it's designed. It would be super cinchy to disable keyword lookups if a scheme is given, but it would still add a www. and a .com to the url if none are provided (although it would be equally cinchy to turn that off.) However, where do you draw the line? Most people expect the www. and .com to be added, since most browsers nowadays do that for you. If we are going to keep that, then keyword lookups should be done also, if the user has them enabled. IMHO, this bug should be marked WONTFIX, since it really doesn't make sense to disable a feature that a user would expect to work when they have enabled the preference. As for the http://host:port/ problem, that will be fixed when the patch to bug 184433 gets checked in.

Shouldn't be WONTFIX yet. More reasonable would be fix it so no keywords if scheme (http://) or a port number (:8080), since those both are clearly URLs, not keywords.

NOTE: Internet Keywords and Domain Guessing are not the same thing: http://www.mozilla.org/docs/end-user/internet-keywords.html http://www.mozilla.org/docs/end-user/domain-guessing.html Hard to say how to implement this, because the scope of IK is poorly defined. Perhaps IK should ignore strings w/ ":", because then URL schemes ("ftp:", "http:", etc.) and hostname's w/ ports ("server:80") would be ignored. The problem w/ these exceptions is that they run afoul of real-world strings. Like "3:00 am". (We have the same problem right now w/ "." being excluded by IK). This might be the type of feature where we have to tweak the behavior several times to understand the best behavior. Please do NOT dupe this to Bug 184433, because although that bug will fix many of the situations where IK fires and upsets people, this bug is different.

The way the code is written, it turns of keywords for any URL that includes a know scheme, then makes https and https an exception. As I said before, it would be super cinchy to disable the exception for http/s. I can do that, but I'm not sure if that is the new goal of the bug, the Summary doesn't make much sense anymore. As for screwing up real world strings like "3:00 am," those are already broken. It never gets anywhere near the keyword code if a colon is in the address bar. Since it appears to be a protocol superficially, but isn't a known unregistered protocol, a sheet pops up saying "The URL is not valid and cannot be loaded." You can only access strings like that by putting |keyword: 3:00am| in the URLBar.

(fixed summary, oops)

Actually, it's not quite as cinchy as I originally thought. For some reason, keywords without the keyword: scheme get wrapped in http:///, so this section of code thinks that it's an http request. I'll look into it some more.

Jerry: maybe I can change the summary to make more sense. I said "URL-like strings", because often when we discuss features like this, there are a lot of things people can type that need to be considered.

The summary makes sense now, so no need to change it. However, it's currently impossible to tell if the text entered into the URL bar was a URL-like string. By the time that it gets to down to the code that is actually invoking the keword lookup, the URL has been sufficiently mangled that it looks like an HTTP URL. I'm going to file a new bug proposing a redesign of the way keywords are handled, once I document how they actually work now. I'm not sure if we should just close this as WONTFIX or make it depend on that yet unfiled bug.

Ok, so which bug is about localhost going into keyword search

bug 178123 pertains to sending localhost to a keyword server if it isn't resolved locally. See bug 213204 comment #6 for why that is the correct behavior.

In firefox I get the same behavior, but unlike as specified on the first comment, there is no option to disable the search keywords. Do I have to open a new bug for firefox, or is there a way to associate this bug with the firefox stream ?

Firefox has a long list of bugs for this; see bug 231720.

John: I'm going to take a look at that bug. Thanks for mentioning it.