Phoenix rocks, but... The most annoying feature in phoenix is keyword search. 1) There should be a option to disable it. Or just make it default: there is a search bar for searching, no? 2) I get really annoyed when I type something localhost:8080 (testing) and the next thing I get is a google search for localhost. This really needs to be fixed: no keyword search should occur if a valid DNS hostname is found. 3) If there are any non-alphanumeric characters (especially ':', '/', '@', '='), the string is definatelly not a keyword search.

this is not a bug. this is intended behavior. if you type a URL that doesn't resolve then you get a google "i'm feeling lucky" result for that string. If you don't like this then set pref("keyword.enabled", false); in your prefs.js and you won't see it happen any more.

I know that option. But for hosts that resolve ('localhost'), this feature should never be invoked. IMO, the option would be more useful that way.

I agree with Marko that this is a bug. Asa's comment when he wontfixed it was incorrect, because "localhost" does resolve.

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

I altered my prefs.js file but it won't solve the problem ie Phoenix does not seem to take this into consideration or maybe I am not doing the right thing. If so, please let me know what to do.

Asa's comment wasn't accurate in what this does. If you type in something that doesn't validate as a URL, it checks for a bookmark keyword match, then proceeds to execute the keyword.URL as the I'm Feeling Lucky quicksearch. set keyword.enabled to false if you don't want this behaviour. Adding a delay for the DNS request to time out/fail is just going to slow down the majority of users, and that isn't acceptable. -> Restoring WONTFIX

Mike, you're also not understanding what this bug is about. If I type "localhost:7777" into the address bar, Firebird *does* look up localhost and try to connect to it. It only starts doing the keyword thing after connecting to port 7777 fails. Fixing this bug does not involve adding any DNS lookups, so it does not involve slowing down users who use the address bar for I'm Feeling Lucky.

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

we hopefully get back a differnt error message from necko on a failure to connect to the port than we would a failure to resolve the host. If so, then we should just error out at the former case. This seems like this is a seamonkey bug that should be fixed there (without breaking firebird's i'm feeling lucky). Darin, does necko give us a unique error mesage for port connection failure? Are there other errors where we should fall dead rather than move through the keyword lookup stuff?

According to nsNetError.h, NS_ERROR_CONNECTION_REFUSED can be generated by contacting a port that isn't responding (I don't know if there's anything else important that might generate this error though?): http://lxr.mozilla.org/mozilla/source/netwerk/base/public/nsNetError.h#152 So maybe it's as simple as removing line 830 from nsWebShell.cpp?: http://lxr.mozilla.org/mozilla/source/docshell/base/nsWebShell.cpp#826

Yes, it's as simple as removing that line nsWebShell.cpp. Actually, the only thing that should be there is the NS_ERROR_UNKNOWN_HOST check. The others are in response to network conditions: NS_ERROR_CONNECTION_REFUSED 1) The host refused the connection (either nothing was listening on that port or the server has the client filtered out.) 2) The network the host is on is not reachable (no route to that network.) 3) The host itself is not reachable (no route to host.) NS_ERROR_NET_TIMEOUT 1) The operation (usually a read or write) timed out, probably due to the connection being lost or the remote server freezing. NS_ERROR_NET_RESET We were able to connect to the host, but remote server reset the connection for some reason (such as the server being restarted.) In all of these cases, the host exists, so it doesn't make much sense to do a keyword lookup. Going back to when the lines were originally added, it looks like it was to make the keyword search more restrictive than it was originally, but it seems to be a little loose still. I'll attach a patch yanking those out.

Comment on attachment 138247 [details] [diff] [review] Yanks out the keyword lookup for network errors, if the host is resolveable. I'd rather darin review this; he knows more about this sort of thing than I do... for the curious, this code was initially added in revision 1.389 of nsWebShell.cpp; the checkin comment is, "We were kicking *any* load failure to the keyword server, now we're a little more selective." I guess we want to be more selective yet. ;)

This is very tightly related to bug 95390.

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

Is this a bug about Internet Keywords design flaws? If so, it needs to be sent to the Browser:Doc Shell component. From searching the Firebird component, there are several bugs in this limbo state. This bug seems to morph between the current summary and "Internet Keywords should be off by default".

RE: comment #16, I don't think that the bug has morphed at all. Nobody is suggesting that keywords be off by default. The attached patch turns off keyword lookup when a host is resolveable, but doesn't respond on the port specified (or is not reacheable due to network conditions.) However, I think you are right about changing the product/component.

Comment on attachment 138247 [details] [diff] [review] Yanks out the keyword lookup for network errors, if the host is resolveable. r=adamlock

Comment on attachment 138247 [details] [diff] [review] Yanks out the keyword lookup for network errors, if the host is resolveable. sr=darin

So is this fix for Firebird-only? It looks like trunk to me. The Netscape design is way out of the picture, I think this is a great improvment, if for no other reason than the people typing localhost are very confused. I don't think Asa and I had thought about this when he initially asked me if using IK by default for Phoenix was a bad idea or not.

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

Re: "people typing localhost are very confused" Absolutely not. From a general end-user POV I may be somewhat unusual, but I run a local webserver for development purposes (and also local storage of certain documentation and standards that I find useful but don't want to take an external net hit for) and I suspect a lot of other people do to - in absolute terms if not in relative terms. So I access http://localhost/stuff?otherstuff quite a bit. Sometimes I've shut it down to edit the webserver conf files, and forgotten to restart before reloading a page, or I've introduced a bug which causes it not to be able to serve pages any more. What I find then is Firebird automatically redirects to http://www.localhost.net.au/, after which I can't just restart Apache and hit reload, I basically have to re-enter the url and renavigate the the page/query by hand. WhyTF would I ever want to go to that site - it's basically a spam domain-squatting site which would never be a useful thing to find. As people have pointed out, if the DNS entry doesn't exist at all, it *might* *sometimes* be appropriate to do a keyword search for it (but then again, my attitude is that if I wanted that I'm quite capable of using Google myself, and if I mistype on occasion I want to be *told* about it, and have the opportunity to correct my speeling or do a search using *my* preferred search engine myself rather than being transparently forwarded to someone elses idea of what I might have wanted/what would be more lucrative for them for me to find. So really I want the option to turn that feature off *completely*.) But if the DNS name *does* exist, but the server is temporarily down I want to know about that, and have the original URL left in the address bar so that once the problem is resolved either by my own action or by giving sufficient time for the remote admins to reboot their server, I can just hit Refresh to load the page I wanted. IK should never be used by default under these circumstances. Perhaps some people might want the option to turn it on, but I really seriously doubt it.

I might also point out the story of Almon Strowger: http://en2.wikipedia.org/wiki/Almon_Strowger He invented the automatic telephone exchange because he believed human operators were secretly diverting calls to his business to his competitors. What IK does in certain circumstances is add back in the automatic facility to divert an end user's desired request to some related business based on who has control of the IK database. Some people might be comfortable with that but I'm not. Please give us the ability to turn it off completely. "No longer will Microsoft steal all my preferred supplier's business just because they paid Netscape or Google a huge pile of dosh."

John: "it" meant "the fix". My dislike of this feature implementation is pretty well documented. The IK setting is configurable (I run a personal IK server myself). The main problem with the current implementation is it was done rather thoughlessly, without special consideration for cases like "localhost", or a good understanding of network errors. Although I never spoke with anyone who designed the original feature, my interpretation of the design is that it sought to maximize the number of excusable situations where a netscape page could be displayed (and potentially monetized).

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

Jerry: do you want to take ownership of this bug? I'd like to get this checked in to the trunk right away.

I don't have perms to take ownership of bugs, or check anything in.

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

checked in Checking in docshell/base/nsWebShell.cpp; /cvsroot/mozilla/docshell/base/nsWebShell.cpp,v <-- nsWebShell.cpp new revision: 1.628; previous revision: 1.627 done

V: Mac OS X, Mozilla 1.7a track, 20040129

V Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040129 Firebird/0.8.0+ localhost went nowhere.

Verified by cdn on Linux.

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

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

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

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

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

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

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

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

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

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