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

VERIFIED FIXED in mozilla0.9.7

Status

SeaMonkey
Search
P3
normal
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: John Dell, Assigned: Samir Gehani)

Tracking

Trunk
mozilla0.9.7

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ready to checkin] 6/13 - Read comments from claudius@netscape.com 2001-09-06 12:14 before commenting)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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)
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.
Assignee: hangas → ben
Status: UNCONFIRMED → NEW
Component: User Interface: Design Feedback → XP Apps: GUI Features
Ever confirmed: true
QA Contact: mpt → sairuh
Summary: Search Button ignores prefs (always goes to netscape) → Search Button ignores prefs (goes to netscape if URL bar contains URL of current page)
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");

      }
}

Updated

17 years ago
Blocks: 14532

Comment 3

17 years ago
I have a patch for this part of code, developed for Beonex. Will check, if it
fixes this.
Assignee: ben → mozilla
Component: XP Apps: GUI Features → Search
QA Contact: sairuh → claudius
odd, this WFM --i'm using linux trunk bits: mozilla *.sea, 2000.11.16.08.

Comment 5

17 years ago
Getting schizophrenic: Moving all bugs for Beonex <http://www.beonex.com> to my
second Bugzilla identity <ben.bucksch@beonex.com>.
Assignee: mozilla → ben.bucksch

Updated

17 years ago
Status: NEW → ASSIGNED
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-

Comment 7

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

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

17 years ago
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.
Assignee: ben.bucksch → matt
Status: ASSIGNED → NEW

Comment 10

17 years ago
Is this bug still occuring?

Comment 11

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

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

Comment 13

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

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

17 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
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

17 years ago
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.)
Keywords: mozilla1.0

Comment 18

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

Comment 19

17 years ago
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.
Keywords: nsbeta1- → nsbeta1
Target Milestone: Future → mozilla0.9.2

Comment 20

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

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

17 years ago
nav triage team:

Not a beta stopper, though, we're pretty sure mozilla wants this fixed.
Keywords: nsbeta1 → helpwanted, nsbeta1-
Target Milestone: mozilla0.9.2 → Future

Updated

17 years ago
Keywords: helpwanted → mozilla0.9.2

Comment 23

17 years ago
*** Bug 82041 has been marked as a duplicate of this bug. ***
*** Bug 83806 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Target Milestone: Future → mozilla0.9.3

Comment 25

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

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

Comment 27

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

17 years ago
*** Bug 83671 has been marked as a duplicate of this bug. ***
cannot reproduce this on linux trunk cvs from today

Comment 30

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

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

Comment 32

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

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

Updated

17 years ago
Keywords: nsbeta1- → nsbeta1+, nsBranch

Updated

17 years ago
Whiteboard: 6/13
nav triage -> m1.0. 
Keywords: nsBranch
Target Milestone: mozilla0.9.3 → mozilla1.0

Comment 35

17 years ago
WFM on Win32 build 2001070206.

Comment 36

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

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

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

16 years ago
No, what you see is another "bug".

Comment 40

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

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

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

Updated

16 years ago
Whiteboard: 6/13 → 6/13 - Read comments from claudius@netscape.com 2001-09-06 12:14 before commenting

Updated

16 years ago
Keywords: mozilla0.9.2

Comment 43

16 years ago
*** Bug 105777 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 44

16 years ago
The search button now take syou to your default engine.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 45

16 years ago
VERIFIED Fixed with 2001103108 builds
Status: RESOLVED → VERIFIED
*** Bug 110990 has been marked as a duplicate of this bug. ***
*** Bug 111860 has been marked as a duplicate of this bug. ***
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
->samir
Assignee: matt → sgehani
Status: REOPENED → NEW
(Assignee)

Comment 50

16 years ago
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.)
Target Milestone: mozilla1.0 → ---
(Assignee)

Comment 51

16 years ago
Worksforme.  Please reopen if problem persists and you can provide additional
steps/conditions to reproduce it.
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 53

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

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

Bug 86063 seams related, although not identical.
(Assignee)

Comment 55

16 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
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."
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 57

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

16 years ago
..mid-air collision, but it seems like bz and I are on the same page
(Assignee)

Comment 59

16 years ago
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.  
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.7
(Assignee)

Comment 60

16 years ago
Created attachment 59387 [details] [diff] [review]
Don't distinguish between unedited and edited URL bar contents.
(Assignee)

Comment 61

16 years ago
morse, please r.
alecf, please sr.

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

Comment 62

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

Comment 63

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

r=morse
Attachment #59387 - Flags: review+

Comment 64

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

me too
sr=alecf
Attachment #59387 - Flags: superreview+
(Assignee)

Updated

16 years ago
Keywords: review
Whiteboard: 6/13 - Read comments from claudius@netscape.com 2001-09-06 12:14 before commenting → [ready to checkin] 6/13 - Read comments from claudius@netscape.com 2001-09-06 12:14 before commenting
(Assignee)

Comment 65

16 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
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.]
Status: RESOLVED → VERIFIED

Comment 67

13 years ago
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.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.