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)
SeaMonkey
Search
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)
(deleted),
patch
|
morse
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
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)
Comment 2•24 years ago
|
||
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•24 years ago
|
||
I have a patch for this part of code, developed for Beonex. Will check, if it
fixes this.
Assignee: ben → mozilla
Updated•24 years ago
|
Component: XP Apps: GUI Features → Search
QA Contact: sairuh → claudius
Comment 4•24 years ago
|
||
odd, this WFM --i'm using linux trunk bits: mozilla *.sea, 2000.11.16.08.
Comment 5•24 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•24 years ago
|
Status: NEW → ASSIGNED
Comment 6•24 years ago
|
||
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this
bug is nsbeta1-.
Keywords: nsbeta1-
Comment 7•24 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•24 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•24 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•24 years ago
|
||
Is this bug still occuring?
Comment 11•24 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•24 years ago
|
||
oh duh, yes this still happens with 2001022109 builds. This behavior is all kinds of broken.
Comment 13•24 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•24 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•24 years ago
|
||
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Comment 16•23 years ago
|
||
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•23 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•23 years ago
|
||
oh, as to how to fix it, see the code snipplet above from navigator.js.
Comment 19•23 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.
Comment 20•23 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•23 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•23 years ago
|
||
nav triage team:
Not a beta stopper, though, we're pretty sure mozilla wants this fixed.
Target Milestone: mozilla0.9.2 → Future
Keywords: helpwanted → mozilla0.9.2
Comment 23•23 years ago
|
||
*** Bug 82041 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
*** Bug 83806 has been marked as a duplicate of this bug. ***
Comment 25•23 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•23 years ago
|
||
(sorry, I overlooked the Target Milestone for this bug :( )
Comment 27•23 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•23 years ago
|
||
*** Bug 83671 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
cannot reproduce this on linux trunk cvs from today
Comment 30•23 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•23 years ago
|
||
(sorry) I forgot - my system is Red Hat Rawhide Linux (current).
Comment 32•23 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•23 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•23 years ago
|
Comment 34•23 years ago
|
||
nav triage -> m1.0.
Keywords: nsBranch
Target Milestone: mozilla0.9.3 → mozilla1.0
Comment 35•23 years ago
|
||
WFM on Win32 build 2001070206.
Comment 36•23 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•23 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•23 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•23 years ago
|
||
No, what you see is another "bug".
Comment 40•23 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•23 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•23 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•23 years ago
|
Whiteboard: 6/13 → 6/13 - Read comments from claudius@netscape.com 2001-09-06 12:14 before commenting
Updated•23 years ago
|
Keywords: mozilla0.9.2
Comment 43•23 years ago
|
||
*** Bug 105777 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 44•23 years ago
|
||
The search button now take syou to your default engine.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 46•23 years ago
|
||
*** Bug 110990 has been marked as a duplicate of this bug. ***
Comment 47•23 years ago
|
||
*** Bug 111860 has been marked as a duplicate of this bug. ***
Comment 48•23 years ago
|
||
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 → ---
Assignee | ||
Comment 50•23 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•23 years ago
|
||
Worksforme. Please reopen if problem persists and you can provide additional
steps/conditions to reproduce it.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 52•23 years ago
|
||
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•23 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•23 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•23 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
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 56•23 years ago
|
||
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•23 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•23 years ago
|
||
..mid-air collision, but it seems like bz and I are on the same page
Assignee | ||
Comment 59•23 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•23 years ago
|
||
Assignee | ||
Comment 61•23 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.
Comment 62•23 years ago
|
||
So besides the cosmetic changes, basically you are removing "searchStr == url"
from an if statement. Looks fine to me.
Comment 63•23 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•23 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•23 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•23 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 66•22 years ago
|
||
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•20 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.
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•