Closed Bug 60283 Opened 24 years ago Closed 23 years ago

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

Categories

(SeaMonkey :: Search, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: jdell, Assigned: samir_bugzilla)

References

Details

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

Attachments

(1 file)

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"); } }
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.
Getting schizophrenic: Moving all bugs for Beonex <http://www.beonex.com> to my second Bugzilla identity <ben.bucksch@beonex.com>.
Assignee: mozilla → ben.bucksch
Status: NEW → ASSIGNED
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this bug is nsbeta1-.
Keywords: nsbeta1-
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.
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.
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
Is this bug still occuring?
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...
oh duh, yes this still happens with 2001022109 builds. This behavior is all kinds of broken.
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?
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.
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
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
oh, as to how to fix it, see the code snipplet above from navigator.js.
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
> 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.
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.
nav triage team: Not a beta stopper, though, we're pretty sure mozilla wants this fixed.
Keywords: nsbeta1helpwanted, nsbeta1-
Target Milestone: mozilla0.9.2 → Future
Keywords: helpwantedmozilla0.9.2
*** Bug 82041 has been marked as a duplicate of this bug. ***
*** Bug 83806 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla0.9.3
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 ?
(sorry, I overlooked the Target Milestone for this bug :( )
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!
*** Bug 83671 has been marked as a duplicate of this bug. ***
cannot reproduce this on linux trunk cvs from today
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 ;-)
(sorry) I forgot - my system is Red Hat Rawhide Linux (current).
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.
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.
Keywords: nsbeta1-nsbeta1+, nsBranch
Whiteboard: 6/13
nav triage -> m1.0.
Keywords: nsBranch
Target Milestone: mozilla0.9.3 → mozilla1.0
WFM on Win32 build 2001070206.
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.
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.
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.
No, what you see is another "bug".
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.
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...
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.
Whiteboard: 6/13 → 6/13 - Read comments from claudius@netscape.com 2001-09-06 12:14 before commenting
Keywords: mozilla0.9.2
*** Bug 105777 has been marked as a duplicate of this bug. ***
The search button now take syou to your default engine.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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
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 → ---
Worksforme. Please reopen if problem persists and you can provide additional steps/conditions to reproduce it.
Status: NEW → RESOLVED
Closed: 23 years ago23 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 → ---
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.
I can easily reproduce this when doing what Stephen described. Build 2001-11-23-08 on Linux. Bug 86063 seams related, although not identical.
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
Closed: 23 years ago23 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 → ---
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?
..mid-air collision, but it seems like bz and I are on the same page
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
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
So besides the cosmetic changes, basically you are removing "searchStr == url" from an if statement. Looks fine to me.
Comment on attachment 59387 [details] [diff] [review] Don't distinguish between unedited and edited URL bar contents. r=morse
Attachment #59387 - Flags: review+
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+
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
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 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
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.

Attachment

General

Creator:
Created:
Updated:
Size: