60283 - Search Button ignores prefs (goes to netscape if URL bar contains URL of current page)

Status: VERIFIED FIXED

(SeaMonkey :: Search, defect, P3)

Description

[John Dell]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001114
BuildID:    2000111404

Sidebar search properly uses preferences (if I specify google in the prefs, it
will search at google).  However, the search button in the URL bar ALWAYS goes
to netscape search regardless of your preferences.  This is totally inconsistent
UI behavior and wrong.  It is understandable that Netscape would want to do this
(although not desireable), but it is not okay for mozilla to do this.

Reproducible: Always
Steps to Reproduce:
Click search button in URL bar.	

Actual Results:  Always goes to netscape search (regardless of user prefs)

Expected Results:  Goes to search page specified in user preferences (i.e. google)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Interesting.  If I change the contents of the url bar (even just typing a
backspace) and then hit the search button it goes to google.  If the URL bar
contains the url of the current page, I get sent to Netscape instead.

Linux trunk build 2000111308.  confirming and changing summary to accurately
reflect the bug.  Over to XP apps.

Comment 2

[Boris Zbarsky [:bzbarsky]]

the culprit seems to be the following if statement (line 713 in
xpfe/browser/resources/content/navigator.js):

	if ((window._content.location.href == searchStr) || (searchStr == ''))
	{
		//	window._content.location.href = defaultSearchURL;
		// Call in to BrowserAppCore instead of replacing
		// the url in the content area so that B/F buttons work right

      if (!(defaultSearchURL == fallbackDefaultSearchURL))
      {
        if (appCore)
          appCore.loadUrl(defaultSearchURL);
        else
          dump("BrowserAppCore is not initialised\n");
      }
      else
      {
        //window._content.local.href =
"http://home.netscape.com/bookmark/6_0/tsearch.html"
        // Call in to BrowserAppCore instead of replacing
        // the url in the content area so that B/F buttons work right
        if (appCore)
          appCore.loadUrl(otherSearchURL);
        else
          dump("BrowserAppCore is not initialised\n");

      }
}

Comment 3

[Ben Bucksch (:BenB)]

I have a patch for this part of code, developed for Beonex. Will check, if it
fixes this.

Comment 4

[sairuh (rarely reading bugmail)]

odd, this WFM --i'm using linux trunk bits: mozilla *.sea, 2000.11.16.08.

Comment 5

[Ben Bucksch (:BenB)]

Getting schizophrenic: Moving all bugs for Beonex <http://www.beonex.com> to my
second Bugzilla identity <[e-mail]>.

Comment 6

[Marcia Knous [:marcia]]

Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this 
bug is nsbeta1-.

Comment 7

[Asa Dotzler [:asa]]

Sorry for the spam, I just wanted to follow knous's comment with a
clarification.  nsbeta1- keyword means that Netscape management has decided that
it will not be able to contribute resources to fixing this for the next Netscape
release.  It does not mean that a fix for this would not be accepted.  Normal r=
and sr= checkin procedure still applies.

Comment 8

[Jim Crumley]

This might be a separate bug, but it seems closely related to this bug as well
as 62140, 32791, etc.

If you put a search phrase in the URL bar that includes a space and hit enter
the search goes to search.netscape.com.  If you hit the search button, it
goes to the search engine in your preferences (google.com, in my case).

This bug appears in the Sparc Solaris Build ID: 2001010221 and Linux Build
ID 2001010410.

This bug (searching through search.netscape.com) also happens if you search
by middle click pasting a search phrade into open space on the browser.

Comment 9

[Ben Bucksch (:BenB)]

I'll reassign to default owner, because I had no time to work on that yet. I
still intend to submit what I do have already.

Comment 10

[Håkan Waara]

Is this bug still occuring?

Comment 11

[Claudius Gayle]

there is some subtlety going on that I think some of the commentors of this bug may have
overlooked. Might explain some of that code snippet as well. There are two different searches to
be done one is when the url bar is 'clean' (you have NOT edited it) and another if it's 'dirty' (e.g. you 
entered a search term).

concentrate on the 'clean' one. In this case the search button is just a regular old hardcoded button
that is not at all context sensitive. I guess the expectation is that in this state it should reflect the
chosen pref for serch engine - i bet it's not even listening...

Comment 12

[Claudius Gayle]

oh duh, yes this still happens with 2001022109 builds. This behavior is all kinds of broken.

Comment 13

[Ben Bucksch (:BenB)]

claudius, if I select Google, it should *never* go to Netscape, no matter, if
the urlbar is dirty or not. (I know that "Internet Keywords" are different.)

> There are two different searches to
> be done one is when the url bar is 'clean' (you have NOT edited it)

What are they?

Comment 14

[Claudius Gayle]

I'm not arguing. I'm just providing info so people know what the bug really is and what we're asking
for. In the 'clean' state the Search button is just a big dumb link to a search(or whatever) page, just
like the toplevel button in NN4.7.
So we just need it in these cases to also respect the pref chosen for internet searches.

so there aren't really two searches - just 1 search and 1 link.

Comment 15

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 16

[Gervase Markham [:gerv]]

This function now looks highly pref-ised (and therefore changeable by
distributors) to me. However, it seems that, whatever your search prefs, we now
go to Netscape Search _whatever_ (URL bar changed or the same.) This, frankly,
sucks.

And, what is worse, the code is so labyrinthine (passing chrome URLs of
properties files to pref requests?) and needlessly involving RDF, that I can't
figure out how to fix it :-( We need it to respect browser.search.defaultname .

Gerv

Comment 17

[Ben Bucksch (:BenB)]

Tha labyrinth is created by the design of the localizable prefs.

You can remove all traces of Netscape by changing default prefs and chrome files
(see Beonex Communicator as proof). But I agree very much that even without
explicit search string, the search engine of the user's choice (prefs UI) should
be used, not Netscape. Not only for idealistic reasons (bug 14532), but also to
meet user expectations.)

Comment 18

[Ben Bucksch (:BenB)]

oh, as to how to fix it, see the code snipplet above from navigator.js.

Comment 19

[matt]

This is actually an easy fix that I was not able to get to in the 0.9.1 time 
frame.   The problem is that sherlock files contain a search URL that expect a 
query string and not the search page.   So my next step is the grab the pref and 
then match for just the domain of the file in the sherlock.  Then of course end 
the user on there way.  Then we can rely on the sherlock file (thus the pref) 
rather then this defaultbackup url stuff.  Please ping me on this bug in 2 weeks 
if we have not gotten this fixed.

Sorry it's a mess but I'm slowely reworking the code rather then just ripping it 
out because of the beta so there are a few cases that I still need to hit.

Comment 20

[Ben Bucksch (:BenB)]

> The problem is that sherlock files contain a search URL that expect a 
> query string and not the search page.   So my next step is the grab the pref
> and then match for just the domain of the file in the sherlock.

I wouldn't make the assumption that the domain name of the search url is the
same as the empty search engine form. IMO, you should use a new var (entry), if
there isn't one already.

Comment 21

[matt]

sure, we could extend sherlock that way but no other sherlock files will ever 
get created with that variable.  The information we have to go on is contained 
in the sherlock file.  Please look at a basic sherlock file and suggest 
something else.

Comment 22

[Paul Chen]

nav triage team:

Not a beta stopper, though, we're pretty sure mozilla wants this fixed.

Comment 23

[matt]

*** Bug 82041 has been marked as a duplicate of this bug. ***

Comment 24

[sairuh (rarely reading bugmail)]

*** Bug 83806 has been marked as a duplicate of this bug. ***

Comment 25

[Martin Macok]

I still get this bad behaviour with latest-0.9.1pre builds (2001060509). (search
button makes me go to netscape but I set the google in preferences.)
Red Hat 7.1 Linux.

Is it going to be fixed in 0.9.1 ?

Comment 26

[Martin Macok]

(sorry, I overlooked the Target Milestone for this bug :( )

Comment 27

[zane]

I'm using Mozilla 0.9.1 build ID: 2001060713, and I can't ever get the search
button to listen to my "internet search" preferences for more than one lookup. 
If I change the preferences to google, and then surf for a while, and then enter
search keywords, and hit "search", it always searches at Netscape.  When I go to
look at the preferences->navigator->internet search page again, it's switched
itself back to netscape.  For me this isn't an issue of different behaviour when
I hit "enter" or click the "search button" when I've entered search terms
(though the fact that those behaviors are different is annoying) - I just can't
save a preference that tells it what I want it to do when I hit search.  It
seems like this is such a simple bug (for something that *worked* in 0.9.0) - it
really should be fixed asap.  Thanks!

Comment 28

[Chris Hiner]

*** Bug 83671 has been marked as a duplicate of this bug. ***

Comment 29

[Doron Rosenberg (IBM)]

cannot reproduce this on linux trunk cvs from today

Comment 30

[Martin Macok]

I can reproduce it on today's build (20010612xx).

Go to preferences, turn on search button (it sometimes turns it off by itself)
and set google as search engine. Try to use the search button several times. Try
to shutdown Mozilla and start it again and use the button several times.

 => somewhere it starts using Netscape search. (and that really sucks ;-)

Comment 31

[Martin Macok]

(sorry) I forgot - my system is Red Hat Rawhide Linux (current).

Comment 32

[matt]

I've fixed bug http://bugzilla.mozilla.org/show_bug.cgi?id=82041
that is causing the pref to revert back to the default (netscape right now)
so you shouldn't have that problem.

The other problem appending the sherlock file when you hit the button and you 
haven't put a search term in the urlbar.

Comment 33

[krappie]

I am still seeing this bug on build 2001062014 on Win98.

I set my search to 'google'.
I type 'blah' in the url bar.
It offers to search with google in the drop-down menu, but I click on the search
button.
It uses the netscape search.
My preference setting is now set on 'Netscape' and the drop-down menu also
offers a Netscape search.
I must change my search preference back to google.

Comment 34

[Viswanath Ramachandran]

nav triage -> m1.0. 

Comment 35

[doctor__j]

WFM on Win32 build 2001070206.

Comment 36

[doctor__j]

I should add more info on my WFM situation.

When I type some words on the URL bar and click Search button, I can actually go
to Google search page (I've chosen Google as my search engine in the Pref.)

BUT, after the Google search page finish loading (i.e., you got a real URL shown
on the URL bar), pressing Search button WILL bring you to the Netscape search page.

Hope I've clarify my WFM statement.

Comment 37

[Claudius Gayle]

doctor j: that is the exact antithesis to 'WFM', what you have described is reproducing the bug
exactly as reported and currently summarized. WFM implies that you do NOT see the bug.

Comment 38

[david_thatcher]

this is occuring in macintosh mozilla build ID: 2001080214 on macos9.1(PPC). I
set my search engine to google, and when I type in a phrase in the address bar
and hit enter, it searches with netscape. when I type in a phrase and click
Search, it searches with google.

Comment 39

[Ben Bucksch (:BenB)]

No, what you see is another "bug".

Comment 40

[matt]

What he is seeing is keywords.  That is the correct behavior.
No one has yet to customize keywords.  You can only turn them on or off.

Comment 41

[earthsound]

I am using Build ID: 2001080110 on Win98 & notice the following behaviors:

In Edit>Preferences>Navigator>Internet Search, I set the Default Search Engine
to Google. 

I open the Sidebar>Search and type in "help", within All Engines, and click
Search. The search is performed on search.netscape.com. It *should* listen to my
prefs & search on Google.

In same Sidebar>Search panel, I type in "help", within either Mozilla or Web,
and click on Search & an Alert pops up and says: "Enter some text to search for
and select at least one location to search", although my prefs say Google. I
would expect at least the Google checkbox to be checked if Google is my
preferred Default Internet Search Engine.

When I type a search term in the URL bar and click the Search button, it uses my
preferred engine, Google, and when I shutdown/reopen Mozilla and click the
Search button to perform my search, the behavior is the same. This is correct,
so this bug WFM, partially. No matter how many times I search via the Search
button, or if I include spaces or other non-alphanumeric characters, the search
goes to Google, with ONE exception:

If I do a search via the search button, the results pop up on Google. If I click
the search button again, w/o changing what's in the URL box, I'm taken to
Netscape's search engine, although the prefs *haven't* changed. This behavior is
repeatable and wrong. Unlike earlier reports, my Default Search Engine remains
the same. If I copy the resulting URL and go to a different page, paste the URL
I copied into the URL box and click the Search button, then it takes me to
Google. So, it appears that it treats the contents of the url box as a keyword
search if the search term = the current page's URL, even if using the Search
button. *shrug* Sorry for the long ramble...

Comment 42

[Claudius Gayle]

sigh. I'm tired of repeating myself. people should not comment in a longstanding
bug without reading the entire bug and being familiar with the historical issues
stated in the bug. Even as I write this I just finished rereading this bug for
the 100th time.</grumble>

This bug is for exactly one issue(i say 'issue' because the behavior is as
designed but the design may be flawed) as follows:

Based on comments here and other feedback it would seem that most people expect
just clunking the 'Search' button (without typing in the url bar) to take them
to the homepage of their preferred search provider as set in the prefs. The
browser is currently designed to take one to netscape search - a hardcoded link.
The developer working on this code has agreed that this makes sense to do but
has stated that the change is non-trivial.

to speak specifically to earthsound's comments since they are elucidated so clearly:

last paragraph(P6) first: - yes that is exactly what this bug is about, nothing
else. When the url bar is 'clean' clicking 'search' is the same as selecting
"search the web" from a menu. We want to change this to reflect the pref.

as far as the sidebar - you are using the Adnvaced search panel - which is for
using multile search engines at the same time. You are supposed to pick engines.
The bug(different bug) is that you didn't get the alert telling you as much.
Even i nthe Basic panel there is a dropdown that's let's you choose and engine.
Could it default to respect your pref?  maybe, but that a different bug.

This bug: make just clicking the search button, aka a 'clean' url bar search
respect the user's search engine pref.

Other bugs: everything else.

Comment 43

[R.K.Aa.]

*** Bug 105777 has been marked as a duplicate of this bug. ***

Comment 44

[Samir Gehani]

The search button now take syou to your default engine.

Comment 45

[Claudius Gayle]

VERIFIED Fixed with 2001103108 builds

Comment 46

[Boris Zbarsky [:bzbarsky]]

*** Bug 110990 has been marked as a duplicate of this bug. ***

Comment 47

[Boris Zbarsky [:bzbarsky]]

*** Bug 111860 has been marked as a duplicate of this bug. ***

Comment 48

[Boris Zbarsky [:bzbarsky]]

Reopening.  I still see this bug with linux build 2001-11-23-08.  Steps to
reproduce:

1)  Start Mozilla
2)  Open preferences
3)  Set default search engine to google
4)  Click on search button (either with the url field blank or with the url
    field showing the current page's url)

Actual results: searches with netscape

Expected results: searches with google

This happens with both an existing profile and a newly created one.

Comment 49

[sairuh (rarely reading bugmail)]

->samir

Comment 50

[Samir Gehani]

Can't reproduce with a 2001-11-26-098-trunk mozilla linux build using Google as
my default engine.  Boris, is this a problem with a new profile?  (Attempting to
eliminate coruption issues.)

Comment 51

[Samir Gehani]

Worksforme.  Please reopen if problem persists and you can provide additional
steps/conditions to reproduce it.

Comment 52

[Boris Zbarsky [:bzbarsky]]

Detailed steps to reproduce:

1) Download 2001-11-26-08 Linux trunk nightly (the .tar.gz, not an installer)
2) Wipe out Mozilla installation with "rm -rf"
3) untar the nightly
4) Start 'mozilla -ProfileManager'
5) Create a new profile names 'aaa' (I'm unimaginative)
6) Start mozilla with this new profile
7) Open preferences
8) Go to Navigator > Search
9) Select google from the dropdown
10) Turn off search sidebar opening
11) Save preferences
12) Quit mozilla
13) Restart mozilla; select 'aaa' profile
14) Click "Search" button.  Goes to Netscape search
15) Clear url bar and click "Search" button.  Goes to Netscape search

reopening.... I can still clearly reproduce this

Comment 53

[Stephen Compall]

Let's clarify. This is the behavior that I have consistently seen in multiple
builds for multiple platforms:

1. if you actually take the time to put some new search terms in, and then you
click search, you will get google.

2. if you just leave the current url in there, or clear it out, you will be sent
to netscape search.

I am still experiencing this as of 2001-11-26-10! And none of this new profile
stuff seems to be necessary.

Comment 54

[André Dahlqvist]

I can easily reproduce this when doing what Stephen described. Build
2001-11-23-08 on Linux.

Bug 86063 seams related, although not identical.

Comment 55

[Samir Gehani]

Regarding comment 52:

Ah, that's a feature.  If the URL of the currently loaded content is the same as
the URL entered in the URL bar (when a user in effect hasn't entered anything
into the URL bar) then we take the user to a search page since they have clicked
the search button.  See:
<http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#731>

If the user types a URL that is different than currently loaded one we pass it
on as a search string to the default search engine, Google in Boris's case.

Comment 56

[Boris Zbarsky [:bzbarsky]]

Reopening yet again.  This "feature" is the whole point of this bug report --
the bug report is a request to get rid of this feature.  Samir, the behavior you
describe as "correct" has been in place all along; see my comment 1.  Also see
Claudius' comment 42 (the one mentioned in the status whiteboard).  He sums up
pretty clearly exactly what the current situation is, what the _desired_
situation is.  The relevant line from that comment: "This bug: make just
clicking the search button, aka a 'clean' url bar search respect the user's
search engine pref. Other bugs: everything else."

Comment 57

[Claudius Gayle]

Samir, I thought we had caved and decided not to fight the user expectation
anymore. Read my comment #42 or just the line before the last for the short
version. And if you read #44 and #45 then it seems that this was working
properly and has regressed again. from lxr, line 732 isn't "otherSearchURL"
supposed to represent the user's search pref choice? Not just always Netscape?

Comment 58

[Claudius Gayle]

..mid-air collision, but it seems like bz and I are on the same page

Comment 59

[Samir Gehani]

Sheesh.  I do apologize for not having read the bug in greater detail
(unintentionally, I assure you).  

So I think the correct thing to do would be to not extend the Sherlock format
but just treat the URL as a search string.  I think users would expect this
since the placement of the search button implies they are searching for the
contents of the URL bar.  Essentially: no differentiation between a 'clean' and
'dirty' string in the URL bar.  

Comment 60

[Samir Gehani]

Attachment: Don't distinguish between unedited and edited URL bar contents.

Comment 61

[Samir Gehani]

morse, please r.
alecf, please sr.

Small patch.  Tested with search button for URL bar in edited as well as
unedited states.  Thanks.

Comment 62

[Stephen P. Morse]

So besides the cosmetic changes, basically you are removing "searchStr == url" 
from an if statement.  Looks fine to me.

Comment 63

[Stephen P. Morse]

Comment on attachment 59387 [details] [diff] [review]
Don't distinguish between unedited and edited URL bar contents.

r=morse

Comment 64

[Alec Flett]

Comment on attachment 59387 [details] [diff] [review]
Don't distinguish between unedited and edited URL bar contents.

me too
sr=alecf

Comment 65

[Samir Gehani]

Checked in.

Comment 66

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]

Comment 67

[Peter Belew]

I have the same problem; in fact whenever I open a new tab with a blank url bar,
enter search text, and hit the search button, it goes to Netscape, even though
I've set Google in my preferences.