Last Comment Bug 184433 - Internet Keywords triggered by "connection refused" errors (hostname not running server on requested port)
: Internet Keywords triggered by "connection refused" errors (hostname not runn...
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: 1.0 Branch
: All All
: -- major with 5 votes (vote)
: ---
Assigned To: Jerry Talkington
: benc
Mentors:
: 178123 187660 222156 224273 225223 226971 239353 243125 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-09 07:22 PST by Marko Macek
Modified: 2014-07-20 05:49 PDT (History)
28 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Yanks out the keyword lookup for network errors, if the host is resolveable. (727 bytes, patch)
2003-12-31 22:07 PST, Jerry Talkington
darin.moz: superreview+
Details | Diff | Splinter Review

Description Marko Macek 2002-12-09 07:22:55 PST
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] 2002-12-24 21:41:06 PST
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 2002-12-24 23:31:06 PST
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 2003-03-09 18:05:02 PST
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 2003-05-08 05:20:11 PDT
*** Bug 204845 has been marked as a duplicate of this bug. ***
Comment 5 Wim Paulussen 2003-05-08 05:50:52 PDT
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] 2003-09-25 17:32:51 PDT
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 2003-09-25 19:45:11 PDT
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 2003-11-10 08:32:36 PST
*** Bug 225223 has been marked as a duplicate of this bug. ***
Comment 9 Asa Dotzler [:asa] 2003-11-25 17:28:53 PST
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 2003-12-10 04:06:34 PST
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 2003-12-31 22:06:09 PST
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 2003-12-31 22:07:31 PST
Created attachment 138247 [details] [diff] [review]
Yanks out the keyword lookup for network errors, if the host is resolveable.
Comment 13 Boris Zbarsky [:bz] 2004-01-01 12:32:51 PST
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 2004-01-01 13:24:47 PST
This is very tightly related to bug 95390.  
Comment 15 Jason Barnabe (np) 2004-01-02 05:24:50 PST
*** Bug 229857 has been marked as a duplicate of this bug. ***
Comment 16 benc 2004-01-06 02:04:29 PST
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 2004-01-06 09:53:24 PST
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 2004-01-06 13:12:04 PST
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 2004-01-07 12:03:06 PST
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 2004-01-15 12:24:28 PST
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 2004-01-15 15:32:16 PST
*** Bug 229229 has been marked as a duplicate of this bug. ***
Comment 22 John Sullivan 2004-01-15 17:13:41 PST
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 2004-01-15 17:38:04 PST
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 2004-01-16 00:02:02 PST
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 2004-01-26 07:30:41 PST
*** Bug 232200 has been marked as a duplicate of this bug. ***
Comment 26 benc 2004-01-26 16:10:02 PST
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 2004-01-26 16:17:53 PST
I don't have perms to take ownership of bugs, or check anything in.
Comment 28 X x 2004-01-27 07:51:43 PST
*** Bug 232200 has been marked as a duplicate of this bug. ***
Comment 29 Christian :Biesinger (don't email me, ping me on IRC) 2004-01-28 13:32:55 PST
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 2004-01-30 03:58:22 PST
V: Mac OS X, Mozilla 1.7a track, 20040129
Comment 31 alanjstr 2004-01-30 05:48:47 PST
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 2004-01-30 08:38:40 PST
Verified by cdn on Linux.
Comment 33 Simon Paquet [:sipaq] 2004-02-01 04:14:08 PST
*** Bug 184814 has been marked as a duplicate of this bug. ***
Comment 34 Simon Paquet [:sipaq] 2004-02-01 04:15:46 PST
*** Bug 232773 has been marked as a duplicate of this bug. ***
Comment 35 Simon Paquet [:sipaq] 2004-02-01 04:16:16 PST
*** Bug 224273 has been marked as a duplicate of this bug. ***
Comment 36 Simon Paquet [:sipaq] 2004-02-01 04:16:27 PST
*** Bug 226971 has been marked as a duplicate of this bug. ***
Comment 37 alanjstr 2004-02-03 15:23:38 PST
*** Bug 178123 has been marked as a duplicate of this bug. ***
Comment 38 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-29 15:57:52 PST
*** Bug 222156 has been marked as a duplicate of this bug. ***
Comment 39 Jeff Walden [:Waldo] (remove +bmo to email) 2004-04-01 20:56:17 PST
*** Bug 239353 has been marked as a duplicate of this bug. ***
Comment 40 Asa Dotzler [:asa] 2004-04-27 14:37:54 PDT
*** Bug 235786 has been marked as a duplicate of this bug. ***
Comment 41 R.K.Aa. 2004-06-13 01:23:19 PDT
*** Bug 187660 has been marked as a duplicate of this bug. ***
Comment 42 Michael Lefevre 2004-06-16 05:38:48 PDT
*** Bug 243125 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.