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

RESOLVED WORKSFORME

Status

P5
enhancement
RESOLVED WORKSFORME
17 years ago
10 years ago

People

(Reporter: steviealexb, Unassigned)

Tracking

Trunk
Future
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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

Comment 1

17 years ago
iirc Not a bug, this can be changed through preferences.
Assignee: asa → alecf
Component: Browser-General → URL Bar
QA Contact: doronr → claudius
(Reporter)

Comment 2

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 5

17 years ago
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

Comment 7

17 years ago
reassign url bar bugs to new owner..
Assignee: alecf → blakeross

Comment 8

17 years ago
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → Future

Comment 9

17 years ago
This was fixed for links to http://mozilla/ in bug 34943.  It's still broken for
typing http://mozilla/ into the location bar.

Comment 10

16 years ago
*** Bug 147119 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
*** Bug 150025 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
*** Bug 164802 has been marked as a duplicate of this bug. ***

Updated

16 years ago
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]

Comment 13

16 years ago
dupe of bug 66183?

Comment 14

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

Updated

16 years ago
Blocks: 63736

Comment 15

16 years ago
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.

Comment 16

16 years ago
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

Comment 17

16 years ago
Forget my last comment. It works (can't tell what's different today, though :( )
Sorry for the spam.

Comment 18

16 years ago
*** Bug 184814 has been marked as a duplicate of this bug. ***
*** Bug 185028 has been marked as a duplicate of this bug. ***

Comment 20

16 years ago
*** Bug 206662 has been marked as a duplicate of this bug. ***
*** Bug 213204 has been marked as a duplicate of this bug. ***

Comment 22

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

Comment 23

15 years ago
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.

Comment 25

15 years ago
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. ***

Comment 27

15 years ago
This should be duped to Bug 184433, since that has a patch.

Comment 28

15 years ago
What if the DNS lookup failed?  In this case it is an intranet URL and a keyword
search should not occur.

Comment 29

15 years ago
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.

Comment 30

15 years ago
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.

Comment 31

15 years ago
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

Comment 32

15 years ago
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.

Comment 33

15 years ago
(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

Comment 34

15 years ago
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.

Comment 35

15 years ago
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.





Comment 36

15 years ago
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.

Comment 37

15 years ago
Ok, so which bug is about localhost going into keyword search 

Comment 38

15 years ago
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.

Updated

14 years ago
Blocks: 235786

Comment 39

13 years ago
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 ?

Comment 40

13 years ago
Firefox has a long list of bugs for this; see bug 231720.

Comment 41

13 years ago
John: I'm going to take a look at that bug. Thanks for mentioning it.
Status: NEW → RESOLVED
Last Resolved: 17 years ago10 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.