After a while, the search popdown in the URL field shows up as: Search undefined for "foo". Selecting it makes Moz try to resolve host "undefinedfoo". Similar to the fixed bug 82041, so assigning to/cc'ing people from there. I get with with Linux 2001062506, a 0_9_2 build! This really should be a blocker.

Still seeing this w/ 2001070908. Sometimes instead of becoming undefined, only the icon disapears, so instead of. ['G' google logo] Search google for 'foo' It's just : Search google for 'foo' Possibly some buffer is overflowing all over this setting, sometimes wiping out the icon location, sometimes which search engine?

Grr, friggin crashed last time just as I was about to submit this, so excuse the brevity. This is related to reinstall. Using Linux installer, search now reverts to 'null' (prev. 'undefined') Using Linux .tar.gz, icon is lost, but still connects to Google OK. Pref's show netscape is selected. setting to google brings back icon.

My last comment is holding true. Also, nothing in prefs.js is changing, when it's broken, and after it's reset. % cat prefs.js|grep search user_pref("browser.search.defaultengine", "engine:///home/jmd/mozilla/25/searchplugins/google.src"); user_pref("browser.search.opensidebarsearchpanel", false); user_pref("browser.toolbars.showbutton.search", false);

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

Am I the only one seeing this? It's a fairly big annoyance. Hasn't been touched in a while.

I have never seen this happen before, but I do not doubt that there are conditions which might cause it to happen.

I haven't seen this bug, and without some semblance of a reproducible testcase it's difficult to track down.

resolving as WFM. If you have steps to consistently repro this bug feel free to reopen.

resolving as WFM. If you have steps to consistently repro this bug feel free to reopen.

I had this problem; given the suggestion that changing the setting in the prefs dialogue cleared it I did a diff between prefs.js before and after selecting google as my search engine (after being the case when the problem was cleared). Here's the key part of the diff: < user_pref("browser.search.defaultengine", "engine://C%3A%5Cmozilla0.9.3%5Cbin%5Csearchplugins%5Cgoogle.src");--- > user_pref("browser.search.defaultengine", "engine://C%3A%5Cmozilla-2001-09-17-09-trunk%5Cbin%5Csearchplugins%5Cgoogle.src"); I deleted the 0.9.3 milestone a while back, but it looks like prefs.js was still referencing a file in it. I guess the fact mozilla couldn't find the file from the old distribution was leading to the "null". I haven't actually gone through the process of installing a new release and deleting the old one (changing directory name in the process) but I suspect that's how you'd reproduce it. Leaving closed for now because I'm not sure this consistently reproduces the bug yet.

As you can probably tell, the above information is from a Windows install while this bug is marked as Linux. It's simple to force the condition under Windows by editing the prefs.js file so that browser.search.defaultengine is a non-existant pathname. However, other comments indicate that using the prefs dialogue wasn't changing prefs.js, so this might not be the same problem. Perhaps others can indicate whether this is the likely cause of their problems.

Mark, I think you have pointed out at least one cause for the reported symptoms that warrants a fix. Nice work!

Taking.

Moving to mozilla0.9.8.

See also 87998 which covers the icon disapearing and search reverting to Netscape in the prefs. I don't suppose we can use chrome:../searchplugins/x.src instead, huh? Is there another protocol that's one level higher then chrome:?

Updating summary. I haven't seen it go to 'undefined' or 'null' for a while now.

I poked this with a stick a few times, and found this is the problem. The pref is set to: (as Mark discovered) engine:///home/jmd/mozilla/11-28/searchplugins/google.src The fix (I imagine) is to eaither make the engine: protocol start under $MOZ_DIR/searchplugins, or to allow the resource: protocol to work for the pref. I manually set it to resource:///searchplugins/google.src, but it didn't work. I don't see a point in engine: being an alias for file:.

engine: is NOT an alias for file: On some platforms (Mac, for example), search files can be in different/multiple directories, sometimes relative and sometimes absolute.

How about if it doesn't start with '/', it's based in $MOZILADIR/searchplugins, then. Then the pref can not use absolute paths and it'll work right.

-> Future

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

This bug makes Mozilla forget your selected search engine if you switch between two Mozilla builds in different directories or between Mozilla and Netscape. I talked to Samir about this bug and we decided that browser.search.defaultengine should be the name of the search engine as displayed in the dropdown (Netscape Search, Google) instead of the filename of the search plugin. We can continue to accept engine:// values in order to preserve backwards compatibility in the case where you install a new version of Mozilla or Netscape in the same directory as an old version, or we can rip out engine:// support and get yelled at once for "resetting everyone's default search engine to Netscape".

> we decided that browser.search.defaultengine should be the name of the search engine as displayed in the dropdown That's a bad decision. It opens up a security issue, for starters, where a 3rd party search engine could maliciously set their name to match that of another and get search requests that weren't meant for them. Also, on some platforms such as Mac (where we get the system's search files as well as Moz's), the situation often pops up where two search engines have the same name.

Finally someone notices this bug from back when milestones started with M. Ditching engine: sounds good since it's the same as file:. Why in the world would you store search engine pref as the name attribute, though? The problem is only that moz currently uses a complete path. What should happen is it just stores, say, 'google.src'. Then you check for $profile_dir/searchplugins/google.src and then for $mozilla_dir/searchplugins/google.src . No, that first part isn't being done at all now, but desperately needs to be. Searchplugins currently need to be installed as root, and only last for that 1 tree. Run-time installed search plugins need to go in the profile. If you're parsing everything in searchplugins/ looking for name=, what happens if two files have the same name? A malicious site could install a search plugin with name = Google (some people are bound to click yes... "oh goodie, google search!). Then when Moz starts, if it reads in malicious.src first, and sees name=Google, searches will go where ever that site wanted.

> Ditching engine: sounds good since it's the same as file: As I said in comment 18, they are not the same.

Comment 18 only explains why engine: can't be rooted inside the mozilla tree. Not why file: just can't be used. Speaking of which, can http: be used? Anyway. Are sherlock files on Mac req'd to be in a certain directory? Seems like there's three placed we'd want to pull a search plugin from. User's profile, mozilla tree, and on mac, sherlock on the mac. How about browser.search.defaultengine for just the src filename, and browser.search.defaultengine.location = 0/1/2 for profile/mozilla/sherlock. Or something similar.

One problem with using filenames instead of names is that Mozilla and Netscape use different filenames for the Google plugin. I don't know how hard that would be to change. I don't think using filenames instead of names would fix the security problem. I think addSearchEngine overwrites your search plugin if the filenames are the same.

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

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

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

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

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

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

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

This blocks profile portability: you lose search capability when you use your Windows profile in Linux, for example.

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

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

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

Now using openSearch backend. Closing