Closed Bug 65911 Opened 24 years ago Closed 23 years ago

Entering free text in URL bar searches using netscape search not default search engine

Categories

(SeaMonkey :: Search, defect, P4)

Product:
SeaMonkey
Component:
Search
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 53171
Milestone:
Future

People

(Reporter: svassall, Assigned: samir_bugzilla)

References

Details

(Keywords: helpwanted) 

Build ID: 2001011804 (Windows 2000)

Description:
Entering free text in the URL/Location bar (e.g. Netscape 6 Review) and then
hitting return always searches using search.netscape.com even if the default
search engine is changed (e.g. to Google).

Expected Behaviour:
The search should be made against the user selected default search engine.

To Repeat:
1. Fire up moz. Open up Prefences dialog and set the default search engine to
google.
2. Enter you prefered free text in the url/location bar and hit return.
3. The search will be performed on search.netscape.com

Repeatability:
Always
*** Bug 65912 has been marked as a duplicate of this bug. ***
Confirmed.  No matter what the default search engine is under Preferences, it
always uses Netscape Search.  

OS: Win2k SP1
Moz Build: 2001011804 Win32 Talkback
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010118
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ummm, I'm pretty sure this has always behaved like this. Hitting enter and clicking search
are very similar but not exactly the same thing.
Hitting search always does a search whereas hitting enter tries to surf to whatever you've typed
if it's not a url then it tries to match it to one, if that doesn't work you are shown the close
matches (what looks like a Netscape search).

I don't know how all of that should affect the status of this bug. All of this behavior is currently
under investigation. - maybe Matt knows more than I about the current status.

Happens on Linux, and probably everywhere else; setting platform/OS accordingly.

I think if it's "always been like this", the obvious question is "Why?" This
behavior seems incongruous, unintuitive, and, well... silly.

This is also the kind of thing that needs to be cleaned up before Mozilla 1.0.
Nominating.
Keywords: mozilla1.0
OS: Windows 2000 → All
Hardware: PC → All
This has something to do with "internet keywords".  I always disable internet
keywords.  When I type terms in the url bar and hit enter, I get a popup that
says something like: "www.Netscape 6 Review.com" cannot be found.  In this case
I would like to see the terms submitted to my search preferences.

Maybe these should be tried when entering text in URL bar:
1) Valid URL - Page displayed in browser.
2) Word - Domain guessing tried.
3) Internet Keywords enabled - Submitted to internet keywords for processing
4) Otherwise submitted to preferred search engine.
This has everything to do with internet keywords.
Internet keywords are use a different code path then the search button.
enter is enter and search is search. _very_ similar but still different. As i understand it if
you type two words in the url bar and hit enter, you hit Internet Keywords code which queries
the Netscape Internet Keywords server (this is not a search server per se), if no match then
that server dumps you into some netscape search results b/c it didn't find a match in its
keywords database.

So you haven't really done a search and the browser never got to repsect your pref choice.

In the case that StephanO describes (keywords pref off) you skip over keywords code and
get that ancient hack of www. your words here.com which doesn't help much. I guess in that
case it would make sense to initiate a search w.r.t. to your search preferences. That seems
like a slightly different bug though.

In the case where you have keywords on, your asking that netscape do a keyword server
search for you and then if that fails send you away somewhere else.

matt, can I get a witness?

I think that those who wish to have hitting enter submit search terms to their
favorite search engine would find it acceptable to disable internet keywords. 
It might be nice to have keywords forward you somewhere of your choosing, but
that seems like a cludge to me.  At least it seems like less of a Mozilla bug
and more like a keywords server RFE.
(Netscape people please don't get annoyed)

I think Internet Keywords should be a value added feature of Netscape Browser,
because it uses Netscape Internet Keywords server to handle the request.

Mozilla browser should do a normal Internet Search when "free text" is entered
on the URL bar.
This is going to get editorial, so diverting to .ui newsgroup.
Depends on: 76547
I am not sure if the user really expect a search function to start, when entering random words into the URL bar.
I get the search function unwanted in most cases, because something did not work fast enough so some tipped letters did not make it into the URL bar and Mozilla thinks it should start a search, which of course failes badly  (bug 72109).
Compare discussion in bug 76547.

I agree that Internet Keywords are different from a search. there is a hidden
pref for the Internet Keywords provider, which in Beonex Communicator I sat to
Google's I'm feeling Lucky, and it works fine and is very useful and cool. It's
just that
- the pref has no UI
- the difference between Internet Keywords and Search is not very clear to users
 (point for you, mpt).

We can discuss, if we want to make "Internet Keywords" do a normal search and
then go to the first result (we can do that, since we can parse the serach
results pages, see search panel). But that would would mean
+ a nicer UI, because we would have only one prefs for both Internet Keywords
  and Search
+ that any search provider can be used, no matter, if it supports that feature
  or not (and no matter, if it *wants* to provide that feature or not).
OTOH, it would have the following disadvantages:
- It would, at least theoretically, limit the possibilities. Currently, the
  Internet Keywords provides *can* be the same as the search provider, but
  doesn't have to.
- It is slower, because the browser has to load a full search page in the
  background, while with I'm feeling Lucky, Google sends just a HTTP REDIRECT
  (or its HTML equivalent).
- It is not implmented and needs more time to implement. It is unclear, if
  Netscape is willing to do that work.

So, I do *not* favor the suggestion, I'm just logging it here.

An alternative would be to add additinal UI for selecting the Internet Keywords
provider.
BenB: "I agree that Internet Keywords are different from a search."

That, obviously, is established fact. The question is, can users be expected to
differentate between an Internet Keyword lookup from the location bar and a
general search from the location bar?

From the user perspective, the distinction is too subtle; the answer is "no".
The conclusion that follows from that answer is that pressing "Enter" while in
the location bar must be made to behave the same as pressing the "Search" button.

There are two ways of correcting this: either make pressing "Enter" behave like
the "Search" button does now (remove Internet Keywords from this UI entirely),
or make the "Search" button behave as pressing "Enter" does now (always use
Internet Keywords from this UI).

Given that a lot of people seem to like Internet Keywords (I really don't care
one way or the other as long as they don't make the browser harder to use), I
suggest that second of these options be pursued. What this means:

The user's default search engine is employed here. If the search engine supports
Internet Keywords (or includes some compatible facility), it will be used
preferentially, and a normal search will be performed if the keyword lookup
yields nothing. If the default search engine does not support Internet Keywords,
then a normal search will always be performed. It probably goes without saying,
but this logic would only be invoked if the browser gets something in its
location bar that is not recognizable as a URI (or something that's supposed to
be a URI).

Does this sound reasonable/feasible?

> pressing "Enter" while in the location bar must be made to behave the same as
> pressing the "Search" button.

I completely disagree, even from a UI perspective. Pressing Enter is like to Go
button, not the Search button. I type myserver and press Enter or click Go, I go
to <http://myserver/>. I type myserver and click Search, I get a search results
page for "myserver". It is just that entering "myserver is cool" and pressing
Enter or clicking Go has no direct reasonable meaning. So, we have to define one.

I do think that Internet Keywords are a good extension for Go. I can use the
term "Beonex Communicator" as "URL" - it works interchangeably with
"http://www.beonex.com/communicator".
I can see the reasoning that Internet Keywords are somthing "in between" Search
and URLs, thus a third mode and thus confusing users, especially since the
access (pressing Enter) is so hidden (so special button for it, which would then
also work for single words like "Apple").
But you need to see that Internet Keywords as I use them are a convient and fast
way to surf.

What about a third (optional) button (in addition to Go and Search), explicitly
for Internet Keywords?

"Pressing Enter is like to Go button, not the Search button."

As long as the Search button is directly adjacent the location bar, lots of
users will expect it to do the same thing as the Go button.

"What about a third (optional) button (in addition to Go and Search), explicitly
for Internet Keywords?"

I think that's the opposite direction to where we should be going. Making the
location bar modal (depending on how text is entered in it) was a Bad Idea. It
is bad design, and we should kill it, not expand it with more modes.


> As long as the Search button is directly adjacent the location bar, lots of
> users will expect it to do the same thing as the Go button.

Well, *that* is a problem, and it needs to be fixed. Search != Go.

We are fixing this problem.
Read the new UI ideas at 
http://www.mozilla.org/projects/ui/communicator/browser/search/
We posted this on the newsgroups a month ago.
I would like to see the "Enter vs Search button behavior" table on
http://mozilla.org/projects/ui/communicator/browser/search/ modified some what
to take into account that the keyword server may be disabled by the user

typing in sitename.com (see Necko url parsing which uses an alg. that looks for
a period being the fourth to last char in the string)
- Hitting Enter Key
- - attempt to resolve URL first, then internal 
- - web server (is this correct?), then send to 
- - keywords server [[[[[[ or send to search engine
- - if keywords are disabled ]]]]]
typing in multiple words sep. by space
- Hitting Enter Key
- - send to keywords server [[[[[[ or send to search engine
- - if keywords are disabled ]]]]]
I disagree with the poster that said using the location bar for multiple
purposes was a Bad Idea.  I think it's great.  But, I agree that just what those
purposes are differs from user to user, and I would like to see it more
explicitly configurable.

Personally, I want it to behave exactly like the search button, unless I've
entered a valid URL. (thus obviating the need for the search button).

I note that right now, when I type in several words, and hit return, and a
search is performed, it is performed with my configured search engine (Google),
but with formatting from Netscape wrapped around the results, which I really
don't like.

Anyway, being a Unix guy I vote for more user definable behavior - let me tell
Mozilla how I want the location bar behave.
> it is performed with my configured search engine (Google),
> but with formatting from Netscape wrapped around the results

Coincidence, because Netscape happens to use Google.

*** Bug 81016 has been marked as a duplicate of this bug. ***
Entering http://localhost/ in the location bar also takes me to netscape search,
which makes testing my local webserver _very_ annoying. This seems like a real
bug in the parser code to me.

Mozilla 0.9 on Linux.
erik@hensema.xs4all.nl, this is bad. Is that a regression (e.g. do you see the
same in 0.6)? Can you fix it by disabling "Internet Keywords" in the prefs?
I think "Entering http://localhost/" is a different problem in necko.
I believe there is a bug filed on the issue but can't find it at the moment.
Enter vs. Search button.  Obviously everyone disagrees.  There is no proven 
evidence one way or another but in UI studies we have found people notice the 
difffence.  Especially as in the netscape branded browser which has the drop 
down keyword list on the left.

As it is I think we provide a decent solution.  Some of you agree, some of you 
disagree.  Unless we come up with something that everyone agrees with or you 
someone can provide concrete evidence that this sux then we should keep what we 
have.  It was based on UI studies and designed by experienced UI designers.  No 
it's not perfect but no one has suggested anything perfect.  As it stands we 
have many ways to disable and configure it so if you hate it then configure it.

Here are you options:
1)Turn it off in the prefs.
2)Go to your all.js file and edit the keyword.netscape.com to whatever you 
please.
3)Build a UI in prefs so you can change the keyword server from the prefs.
4)Build a UI and extend the sherlock parser in search to include a keyword 
attribute.  Then when you change your engine it will also change this pref to 
the keyword you want.  But remember not all search engines have a keyword 
server.  What happens then?
5)For all I care, point the keyword as default to google.  I just think the 
netscape keyword server is a million times better since it does searchs if it 
can't find the keyword.
6)Turn keywords off by default in the prefs.

Keywords are a very powerful thing.  Look at AOL.  It is build on keywords.  
We've designed this so you can configure it. I would hate to tear technology out 
of mozilla because people don't know how to configure the technology.
I've disabled keywords long ago because of this unwanted behaviour.  The last
two or three nightlies I've downloaded have been buggy in that, no matter which
method I use to search (either hitting enter <which -did- always worked before>
or using the search button) the search is not only performed on Netscape, but
after searching the preference option is actually changed to Netscape's search
rather than google.  

The only way I've found to avoid this is to click the bar that automatically
drops down during the typing, which, if I've re-set my prefs back to google,
will search on google and leave the prefs alone.  Up until the nightly I'm
currently using, this hasn't done anything for me, so this part is at least
good.  (That it is now working, that is.)

OS:         W95B (4.00.950 B)
Moz Build:  2001053020 Win32 Talkback (zip)

Lythande, that is bug 82041
*** Bug 83815 has been marked as a duplicate of this bug. ***
worksforme:
1. Closed Mozilla.
2. Opened all.js .
3. Changed
'pref("network.search.url","http://cgi.netscape.com/cgi-bin/url_search.cgi?search=");'
to 'pref("network.search.url","http://www.google.com/search?q=");'.
4. Opened Mozilla.
5. Edit -> Preferences -> Navigator -> Internet Search -> Search Engine -> Google.

Donno why, working perfectly now.
Also, Google were kind enough to make a page explaining about "Adding Google to
Mozilla", including a nice tip for keyword searches: you can set "gg Hack Furby"
to do a Google search after "Hack Furby".
http://www.google.com/mozilla/google-search.html
It seems that using the button to right of the location bar, apart from going to
Netscape's website to do the search, it also resets one's preferred search
engine in the preferences, i.e. it sets it back to Netscape Search.
Frank Sørensen, that's another bug that is already fixed, iirc.
I have just discovered this myself, so I vote for this as a bug, 
I was suprised as any one to see a netscape search page come up!
(yep I'm another google fan - with search preference set to google)


since the intuitive expectation is that this does the same thing as hitting the
search button let's make hitting 'enter' do the same thing?
Assignee: matt → sgehani
Target Milestone: --- → mozilla0.9.7
Need to investigate if the keyword server is redirecting this to a Netscape
search page or if the search engine is configurable for mozilla builds.  
Samir, you can hack prefs.js, if you know the exact URL of the new provider.
There is no UI.
Ben,
Are you referring to the keyword server or to the search page that the browser
goes to after the keyword server?  I need to browse the code to see if the
search page that is visited after the keyword server is controlled by the client
or the server itself.
Samir, I don't know what you mean with the "keyword server" vs. "the search page
that the browser goes to after the keyword server". You can alter the URL the
browser goes to for Internet Keywords. Try to use that:
pref("keyword.URL", "http://www.google.com/search?btnI=I%27m+Feeling+Lucky&q=");
Now, if you use the Internet Keywords feature, you go directly to the first
Google hit (because Google Redirects you there).
*** Bug 100813 has been marked as a duplicate of this bug. ***
Someone correct me if I'm wrong, but it looks like the only resolution to this
(aside from disabling Internet Keywords, which is already possible) is to remove
Internet Keywords--and that is a matter for bug 76547. Marking as a duplicate.

*** This bug has been marked as a duplicate of 76547 ***
Status: NEW → RESOLVED
Closed: 23 years ago
No longer depends on: 76547
Resolution: --- → DUPLICATE
Braden, you are wrong. If nothing else, we can do a normal search, then parse
it, then load the first result in the search page, all while never showing the
search page or search pane in the sidebar.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Ben, it looks to me like the decision even to redirect to a search engine is one
made by the keyword server. So the client could not assume that there is a
search result to parse. Am I mistaken about this?
Braden, as I understood this bug, the people voting for this bug want to see
directly the first result of their favorite search engine. Not all search
engines offer a feature like Google's I'm Feelling Lucky or Netscape's Keywords,
where the server sends an HTTP redirect. So, if we want this feature to work
consistently, we cannot rely on the server. We will have to do a normal search
(like we do today, i.e. we can rely that there is something parsable), then
parse, then load the first result.
This bug was filed in response to behavior that is a by-product of having
Internet Keywords enabled; behavior for which the keyword server is responsible.
I do not see how your suggestion solves that problem.

Braden. the problem here is that the Internet Keywords provider (currently
Netscape, no Prefs UI) doesn't match the search provider (has prefs UI). My
suggestion solves that.
Moving to mozilla0.9.8.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Am using Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011111

In previous builds [few weeks ago] I could do a search by entering free text in
the address bar, hitting the down arrow [on my keyboard] and enter. Voila - goes
straight to the search engine of my choice.

I sorely miss this and would be grateful if you'd bring this back. It's a pain
to click the search button with the mouse!
Moving to milestone after mozilla0.9.9 (mozilla1.0 for now).
Keywords: nsbeta1+
Priority: -- → P4
Target Milestone: mozilla0.9.8 → mozilla1.0
see also bug 79655

folks interested in this bug probably want to send search engine queries via the
internet keywords feature. If so, you're probably interested in the fact that
queries with a dot character will supress internet keywords, which severely
limits the sorts of queries you can send.

The fix is small (two lines) if anyone can fix it readily, or walk me through
how to do so. See bug 79655 for details.

-matt

adding oeone keyword
Keywords: oeone
Search triage team: -> Future
Keywords: helpwanted
Target Milestone: mozilla1.0 → Future
*** Bug 123512 has been marked as a duplicate of this bug. ***
Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.
Target Milestone: Future → mozilla1.0
The nsbeta1+ was legacy cruft from way back when I was triaging and the only way
I was allowed to leave things in mozilla1.0 was by nsbeta1+'ing the bug.  Moving
back to Future.
Keywords: nsbeta1+
Target Milestone: mozilla1.0 → Future

*** This bug has been marked as a duplicate of 53171 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
V:dupe
Status: RESOLVED → VERIFIED
QA Contact: claudius → benc
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.