User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 When right clicking on highlighted text within my browser, I click the "Web Search For" button and receive : Not Found The requested URL was not found on this server. AOLserver/3.2 on http://search.netscape.com:8082 Reproducible: Always Steps to Reproduce: 1. Highlight text in your browser 2. Right click and select "web search for" 3. See the error in the new window Actual Results: Not Found page Expected Results: Brang me to a search results page

.

Happens to me, too.

bah, missed out: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031004 Firebird/0.7+

happens to me as well Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 We shouldn't depend on netscape.com providing services. Can we get this fixed for 1.4.1 and 1.5?

There are three issues: 1. A new profile shows Bugzilla as the default Internet Search but uses Netscape. I originally saw this with an older profile that had the initial setting for Preferences->Navigator->Internet Search of Bugzilla. For some reason it used the search.netscape.com/cgi-bin/ url. New profiles created using 1.4.1 or the trunk still show Bugzilla as the default search engine but use an info.netscape.com address which is properly redirected to a working url on search.netscape.com. 2. There are several occurences of http://search.netscape.com/cgi-bin/search?search= which is a 404. See http://lxr.mozilla.org/seamonkey/search?string=search.netscape.com%2Fcgi-bin Once I started changing the default search engine I could not reproduce the search.netscape.com/cgi-bin 404 problem. 3. Setting Mozilla.org as the default search uses old htdig search pages http://www.mozilla.org/htdig-cgi/ which is also a 404.

Considering bug 213822, I don't know what should be done for this bug, but here is a stab at resolving some of the issues on the 1.4 branch. Since we have already shipped browsers that point to some of these sherlock files on www.mozilla.org/projects/search, I think we should at least update the bugzilla.src and mozilla.src on www.mozilla.org regardless of what is done in bug 213822. Note that this patch probably does too much. 1. Updates embedding/browser/activex/tests/cbrowse/CBrowseDlg.cpp to update the mozilla search url from htdig to google. 2. Updates xpfe/browser/resources/locale/en-US/region.properties and xpfe/communicator/resources/locale/en-US/region.properties to replace the old NSCP cgi-bin search with the new url. 3. Updates xpfe/components/search/datasets to a) fix NetscapeSearch to use new URL, to locate the search results so the sidebar search panel is updated properly, to make the Next/Prev buttons in the sidebar search panel work (Note the sponsored links are part of the list) b) fix bugzilla.src to locate results so the sidebar search panel is updated properly. c) fix mozilla.src to use the new google search pages instead of the old htdig ones. d) change all files to use a 1 day update interval.

Even if we can't fix the browser's versions of these files, can't we at least update the versions on http://www.mozilla.org/projects/search/ ?

Patch Cv2 in bug 225490 fixes what this bug originally was about. (Another patch in that bug has already removed the Netscape search engine and _tried_ (?) to make Google the default, Cv2 only does some cleanup.) Patch Cv2 there largely fixes the first two of the issues mentioned in comment #5, I'll leave the last one to the patch in this bug, which promises an extensive search engine cleanup...

Hmmm... issue 1.) from comment #5 is not fixed by the mentioned patch; there seems to be a different problem that makes always appear the topmost search entry in the list when the search engine has not been explicitly set with the version of Mozilla being used (or something like that). Also note that there is no search engine icon in the urlbar dropdown while this problem is in effect. But the name of the search engine is there and searching works. (This does not prevent the mentioned patch from fixing this bug in its original form...)

Sorry for producing so many comments, but I think I found the problem mentioned in my last comment: The pref "browser.search.defaultengine" saves the location of the search plugin, (e.g. "engine://H%3A%5CPrograms%5Cmozilla%5Csearchplugins%5Cgoogle.src") and this plugin is NOT in the profile, but in the application directory. Therefore when using a profile with two or more Mozilla binaries in different directories, this pref points to not currently used application directories. http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/content/pref-search.xul#44 loads this pref and things get confused... This is why it probably should only happen with different Mozilla installations/paths.