184433 - Internet Keywords triggered by "connection refused" errors (hostname not running server on requested port)

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Marko Macek]

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.

Comment 1

[Asa Dotzler [:asa]]

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.

Comment 2

[Marko Macek]

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.

Comment 3

[Jesse Ruderman]

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

Comment 4

[Gilles Durys]

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

Comment 5

[Wim Paulussen]

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.

Comment 6

[Mike Connor [:mconnor]]

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

Comment 7

[Jesse Ruderman]

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.

Comment 8

[Bill Mason]

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

Comment 9

[Asa Dotzler [:asa]]

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?

Comment 10

[PikeUK]

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

Comment 11

[Jerry Talkington]

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 12

[Jerry Talkington]

Attachment: Yanks out the keyword lookup for network errors, if the host is resolveable.

Comment 13

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 14

[alanjstr]

This is very tightly related to bug 95390.  

Comment 15

[Jason Barnabe (np)]

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

Comment 16

[benc]

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".

Comment 17

[Jerry Talkington]

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 18

[Adam Lock]

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

r=adamlock

Comment 19

[Darin Fisher]

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

sr=darin

Comment 20

[benc]

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.

Comment 21

[Jesse Ruderman]

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

Comment 22

[John Sullivan]

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.

Comment 23

[John Sullivan]

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."

Comment 24

[benc]

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).

Comment 25

[WD]

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

Comment 26

[benc]

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

Comment 27

[Jerry Talkington]

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

Comment 28

[X x]

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

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 30

[benc]

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

Comment 31

[alanjstr]

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

localhost went nowhere.

Comment 32

[alanjstr]

Verified by cdn on Linux.

Comment 33

[Simon Paquet [:sipaq]]

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

Comment 34

[Simon Paquet [:sipaq]]

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

Comment 35

[Simon Paquet [:sipaq]]

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

Comment 36

[Simon Paquet [:sipaq]]

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

Comment 37

[alanjstr]

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

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 39

[Jeff Walden [:Waldo]]

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

Comment 40

[Asa Dotzler [:asa]]

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

Comment 41

[R.K.Aa.]

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

Comment 42

[Michael Lefevre]

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