Closed Bug 95390 Opened 23 years ago Closed 16 years ago

Internet Keywords: should not search when URL-like strings are used

Categories

(SeaMonkey :: Location Bar, enhancement, P5)

Product:
SeaMonkey
Component:
Location Bar
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: steviealexb, Unassigned)

References

(
URL
)

Details

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.
Assignee: asa → alecf
Component: Browser-General → URL Bar
QA Contact: doronr → claudius
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)
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
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
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
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.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: other → All
Hardware: PC → All
reassign url bar bugs to new owner..
Assignee: alecf → blakeross
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → Future
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. ***
URL: Any non-existent intranet url such as... → http://machine:portwithnowebserver/
Summary: Non existent intranet URLs always spawn Internet Searches → Non existent intranet URLs always spawn Internet Searches [http://localhost/ -> http://www.localhost.com/] [auto-complete]
dupe of bug 66183?
*** Bug 178123 has been marked as a duplicate of this bug. ***
Blocks: 63736
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.
Assignee: hewitt → location-bar
Status: ASSIGNED → NEW
QA Contact: claudius → benc
Summary: Non existent intranet URLs always spawn Internet Searches [http://localhost/ -> http://www.localhost.com/] [auto-complete] → Internet Keywords: should to search when URL-like strings are used
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)
Summary: Internet Keywords: should to search when URL-like strings are used → Internet Keywords: should not search when URL-like strings are used
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.
Blocks: 235786
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.
Status: NEW → RESOLVED
Closed: 23 years ago → 16 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.