Closed Bug 184433 Opened 22 years ago Closed 21 years ago

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

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Version:
1.0 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Marko.Macek, Assigned: jtalkington)

References

Details

Attachments

(1 file)

Yanks out the keyword lookup for network errors, if the host is resolveable.
727 bytes, patch
darin.moz
: superreview+
Details | Diff | Splinter Review 
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Summary: keyword search suckage on valid URL → keyword search suckage on valid URL
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: keyword search suckage on valid URL → keyword search triggers for hostname that resolves if port is closed (e.g. localhost:7777)
*** 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.
QA Contact: asa
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
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
*** 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.
Attachment #138247 - Flags: superreview?(bz-vacation)
Attachment #138247 - Flags: review?(adamlock)
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.  ;)
Attachment #138247 - Flags: superreview?(bz-vacation) → superreview?(darin)
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".
QA Contact: benc
Summary: keyword search triggers for hostname that resolves if port is closed (e.g. localhost:7777) → Internet Keywords: triggers for hostname that resolves if port is closed (e.g. localhost:7777)
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
Attachment #138247 - Flags: review?(adamlock) → review+
Comment on attachment 138247 [details] [diff] [review]
Yanks out the keyword lookup for network errors, if the host is resolveable.

sr=darin
Attachment #138247 - Flags: superreview?(darin) → superreview+
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. ***
Blocks: 178123
Jerry: do you want to take ownership of this bug? I'd like to get this checked
in to the trunk right away.
No longer blocks: 178123
Summary: Internet Keywords: triggers for hostname that resolves if port is closed (e.g. localhost:7777) → Internet Keywords: "connection refused" errors (hostname not running server on requested port)
Blocks: 178123
I don't have perms to take ownership of bugs, or check anything in.
Summary: Internet Keywords: "connection refused" errors (hostname not running server on requested port) → Internet Keywords triggered by "connection refused" errors (hostname not running server on requested port)
*** Bug 232200 has been marked as a duplicate of this bug. ***
Assignee: blake → jtalkington
Status: REOPENED → NEW
Component: General → Embedding: Docshell
Product: Firebird → Browser
Version: unspecified → 1.0 Branch
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
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
V: Mac OS X, Mozilla 1.7a track, 20040129
Status: RESOLVED → VERIFIED
Whiteboard: checkwin, checklinux
V Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040129
Firebird/0.8.0+

localhost went nowhere.
Whiteboard: checkwin, checklinux → checklinux
Verified by cdn on Linux.
Whiteboard: checklinux
*** 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. ***
No longer blocks: 178123
*** 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. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: