Closed Bug 65911 Opened 25 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: 24 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: 24 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.