User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030513 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030513 Mozilla Firebird/0.6 I use Google as my search in the search bar, but it doesn't stay all the time. If you send Mozilla Firebird with a URL as a parameter, it forgets the search bar's engine. Reproducible: Always Steps to Reproduce: 1. Change your Search Toolbar to use Google. 2. Note the change in icons. 3. Close Mozilla Firebird. 4. Open Mozilla Firebird. 6. Note the G (for google) is still there. 6. Close Mozilla Firebird. 7. Run MozillaFirebird.exe (or phoenix.exe) from the command line with a URL as the parameter (ie. "C:\Program Files\MozillaFirebird\MozillaFirebird.exe" http://www.mozilla.org). Actual Results: The search icon (and the searching function) is now the default "Find in this Page". Expected Results: Mozilla should have kept my settings. I'm having issues between computers. I can make this happen everytime on Win2k with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030513 Mozilla Firebird/0.6 (the second release) at work, but where I really see the problem is on my computer at home on WinXP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030513 Mozilla Firebird/0.6, and it doesn't happen using these steps. On the Win2k machine, Mozilla Firebird is not the default. On the WinXP, Mozilla Firebird is the default. Specifically, I have Trillian Pro on my WinXP machine, and when I try to open a link from there, it opens my default browser with a URL as the parameter, and the search toolbar becomes forgetful, which prompted me to investigate and file this bug.

WFM using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030514 Mozilla Firebird/0.6 having multiple profiles, i.e. the "select a profile" dialog comes up before Firebird starts - don't know if this is important? -> will give it a second try on our Win2k & WinXP box

WFM using Gecko/20030514 Mozilla Firebird/0.6 on Win2k and WinXP. On both boxes I used to have only one default profile for Firebird so no profile selection dialog came up before Firebird starts... Did I missed an important thing in order to be able to reproduce this bug? - tried on both with firebird as default browser and with an default browser other than firebird - tried on both with firebird called from command line from within the firebird application directory and from c:\ - tried on both with preceding "http://" before the URI and without but had no luck...

OK, your comments made me test a bit further. I incorrectly assumed it was the parameter that was causing it problems. Turns out, it is the capitilzation of the path that calls the program. I've self-verified this on two win2k machines and my personal winxp machine. Common Instructions: 1. rmdir /s /q "C:\Program Files\MozillaFirebird" 2. rmdir /s /q "C:\Documents and Settings\username\Application Data\Mozilla" 3. rmdir /s /q "C:\Documents and Settings\username\Application Data\Phoenix" 4. Unzip http://ftp.mozilla.org/pub/phoenix/nightly/2003-05-14-15- trunk/MozillaFirebird-win32.zip to "C:\Program Files\" 5. Create a shortcut to the program making sure the target is "C:\Program Files\MozillaFirebird\MozillaFirebird.exe" and it starts in "C:\Program Files\MozillaFirebird" (case sensitive). 6. Execute the program via said shortcut. 7. Change the search toolbar to use Google and note the G. 8. Close Mozilla Firebird. 9. Execute the program via said shortcut. 10. Note the same G that you left it at. 11. Close Mozilla Firebird. 12. Go into the command prompt (cmd.exe). 13. Run "c:\program files\mozillafirebird\MozillaFirebird.exe" (the actual program name is case sensitive in XP, but can be lowercase in 2k). 14. Note the G has been replaced by the magnifying glass. Here are my test cases, where it results in google like it should (pass) or reverts back to the magnifying glass (fail). All these tests were done in Win2k. "c:\program files\mozillafirebird\mozillafirebird.exe" [FAIL] "C:\PROGRAM FILES\MOZILLAFIREBIRD\MOZILLAFIREBIRD.EXE" [FAIL] "C:\Program Files\MozillaFirebird\MozillaFirebird.exe" [PASS] "C:\Program Files\MozillaFirebird\mozillafirebird.exe" [PASS] "c:\Program Files\MozillaFirebird\mozillafirebird.exe" [FAIL] "c:\Program Files\MozillaFirebird\MozillaFirebird.exe" [FAIL] "C:\Program Files\Mozillafirebird\MozillaFirebird.exe" [FAIL] "C:\PROGRAM FILES\MOZILLAFIREBIRD\MozillaFirebird.exe" [FAIL] As you can see, the path that calls the program must respect actual case, or the settings are lost. I have programs that seem to convert paths to lowercase before calling, so I see this bug often. I hope this helps.

Mike, thanks for the clarification - now I'm able to reproduce the problem and I second your assumption, that only the Path used when calling Mozilla Firebird from within another directory needs to have the exact same case - the case of the executable name is not of relevance. Nevertheless this seems to be a SeaMonkey bug, though SeaMonkey hasn't got this nice search bar: - extract latest SeaMonkey into a case sensitive directory - start SeaMonkey Browser via Explorer or Shortcut and goto 'Edit' -> 'Preferences' -> expand 'Navigator' -> 'Internet search' - on the right pane switch 'Search using' from "bugzilla@mozilla.org" to "Google" - exit SeaMonkey - restart using explorer or shortcut and ensure that still google is set as search engine in the Preferences - now start SeaMonkey with a "wrong" path by either using command line or creating a new shortcut, where you just need to change the "Target" in the shortcut properties => SeaMonkey also resetted the Search engine to bugzilla@mozilla.org! I found out, that SeaMonkey "remebers" the search engine for every "new" path, so if you start SeaMonkey with "c:\program Files\..." and set the search engine to "Google" it remembers Google everytime you call SeaMonkey with "c:\program Files\..." but if you call it with "c:\Program Files\..." (note the upper case 'P') it resets it to bugzilla@mozilla.org Simon, once again I have to ask you for your help ;) Can I move this one over to Mozilla? I'm not sure whether Mozilla Firebird uses different coding here though it seems like this bug is based on the original SeaMonkey bug I discovered above...

Hi Erik, I can confirm this bug for Mozilla Firebird, but cannot confirm it for Seamonkey's Navigator using the latest Nightly. I tried it with the following paths: C:\Programme\Mozilla\bin\Mozilla.exe c:\programme\mozilla\Bin\Mozilla.exe It always brought up Google on Seamonkey, as intended. Using the following paths under Mozilla Firebird c:\programme\MozillaFirebird\MozillaFirebird.exe C:\Programme\MozillaFirebird\MozillaFirebird.exe brought up this bug. I recommend testing this further, before moving this over to Seamonkey.

By Seamonkey, I'm assuming you mean http://ftp.mozilla.org/pub/mozilla/nightly/2003-05-15-12-trunk/mozilla-win32.zip, so if I'm right, I'll go ahead and further test it for you (if I'm not right, please show me how to get Seamonkey). I thought it might be a problem with spaces in the path, so I tested both "Program Files" and your Programme directories. Both tests (under Win2k) came out the same. 1. rmdir /s /q "C:\Documents and Settings\username\Application Data\Mozilla" 2. rmdir /s /q "path\to\mozilla" 3. Unzip http://ftp.mozilla.org/pub/mozilla/nightly/2003-05-15-12-trunk/mozilla-win32.zip to "C:\Programme\Mozilla". 4. Using Windows Explorer, verify that the path to mozilla is "C:\Programme\Mozilla\bin\mozilla.exe". 5. Using Windows Explorer, double click on mozilla.exe to run the progam. 6. Edit -> Preferences -> Navigator -> Internet Search. 7. Switch the default search engine from Bugzilla@mozilla.org to Google. 8. Hit OK. 9. Close Mozilla. 10. Using Windows Explorer, double click on mozilla.exe to run the progam again. 11. Edit -> Preferences -> Navigator -> Internet Search. 12. Note that Google is still the default search engine. 13. Hit Cancel. 14. Close Mozilla. 15. Go into the command prompt (cmd.exe). 16. Run "C:\PROGRAMME\MOZILLA\BIN\MOZILLA.EXE". 17. Edit -> Preferences -> Navigator -> Internet Search. 18. Note that Bugzilla@mozilla.org is incorrectly the default search engine. Note for testing's sake: I did all this testing with Mozilla Firebird open so I could type out this report. I'm pretty sure that this is a mozilla (Seamonkey?) problem that surfaced (for me) in Mozilla Firebird because of the high visibility the search toolbar has in that browser.

Mike, yes - you're right with your assumption concerning SeaMonkey. So interestingly you get the same results like I get this morning: Mozilla (Seamonkey) switches also back to bugzilla@mozilla.org as search engine. Currently I'm not sure which OS Simon used so perhaps it's also OS dependent, but I was not able to do some more testing on different OSs today...

Testing? I can do that. :) I can confirm that this bug occurs in WinXP using the steps I wrote in comment 6 for both the "Program Files" and Programme directories. I can *not* reproduce this bug in Windows 98. I tried in both paths. Google stayed up every time. Note that this win98 computer is old, has bad hardware, and bad software, and is a big pile of junk. However, I don't see how being a big pile of junk would fix this problem. I'm guessing it only effects NT-based machines, though I don't have an NT computer to test it on.

Well, I don't suppose there to be the need of real more testing since the bug is confirmed and marked as "new" and the devs have some testcases to reproduce the bug. It's just the question why Simon was not able to reproduce this baby in Seamonkey like we did - but that's more of personal interest ;o)

Correct me if I'm wrong, but the search engine is still whatever you picked. It's just that the icon is the magnifying glass instead of, for example, the G for Google. If you use the field to search it will still search using Google.

this.currentSearchIcon is null in search.xml when this happens. No idea why.

|aDS.GetTarget| isn't returning anything for |n| in |readRDFString|. This makes me think the problem is in nsInternetSearchService.

Interesting. It looks like the .src file is read a second time the times this bug happens. When the search engines are loaded as nsInternetSearchService initializes, the path to each .src file uses the case of the command line. InternetSearchDataSource::FindData - reading in 'G:\MOzsrc\obj-fb-dll\dist\bin\searchplugins\dmoz.src' Later, when trying to read the icon in, FindData loads the data again. The path looks to be the defaultengine value from prefs.js. RDF data sources are indexed using a hash table, so InternetSearchDataSource::FindData - reading in 'g:\mozsrc\obj-fb-dll\dist\bin\searchplugins\dmoz.src' So it reads the file in a second time. So what, that shouldn't be a problem, should it? Well, it seems to be causing this problem as far as I can tell. This explanation is pretty consistent with how changing the case of file path can trigger this bug. I could hack around this by doing something like making sure the search .src file paths are in all caps when adding them to the hash table, but that's just hacking around the problem above. This looks like an RDF problem to me, not specifically Firebird, which would explain why some people see this in Mozilla as well (comment 6). I don't understand how reading the file in a second time messes up getting the icon uri. CC:ing any name I can find related to RDF. Of course, I'm running on six hours sleep in the past two days, so feel free to tell me I spent today on a wild goose chanse.

Taking QA Contact

Pierre's search re-write should hopefully have fixed this.

No, I don't think so. But the funny thing is that while I was rewriting it I noticed a big non-sense in the way the engines are identified internally. Unlike other resources, the path of the application directory is used ex: "engine:///home/chanial/mozilla/.../google.src" and this is what is stored in the profile... So another step to reproduce this bug is to move the application directory and we're screwed. When I'll fork nsInternetSearch.cpp, I will fix that. But I don't know precisely when... With my changes, I don't know what happens. In case of failure it should set the icon to find in page, but I have to check that.

bug still occurs in 20031208

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

pierre, any chance of fixing this before 0.8?

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

isn't this a du^plicate of #187293 ? Actually I got the google engine replace by the "search in this page" everytime I restart firebird...

-> 0.8

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

(inherits Firebird0.8 target milestone and blocking0.8+ status from the bug I made a duplicate of this)

temporary fix checked in. kicking out to .9

I am now getting this error in JS console Error: uncaught exception: [Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsILocalFile.initWithPath]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: chrome://browser/content/search.xml :: initialize :: line 31" data: no] Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20040102 Firebird/0.7+ Ben's checkin is http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&file=search.xml&rev1=1.13&rev2=1.13.2.1&root=/cvsroot

search engine seems to be reverting to Find in Page

I take that back, it stayed Google this time. But the error definitely seems to come from ben's patch.

Ok, the error seems to appear if Find in Page is my chosen search engine and then I restart the browser.

The patch on Jan 3rd ended up causing problems on Mac OS X. Search engines started disappearing after a restart from that date on. I revered back to a nightly build from Jan 2nd and they stay put. The error I've been seeing, on Mac OS X 10.3 Panther with Firebird latest builds is by either copying over or installing new search engines. They disappear when restarting Firebird.

changes flags according to Ben's instructions on IRC (and comment 26)

i'm having this bug as well: i'm running Firebird "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040120 Firebird/0.8.0+" only although all search engines are lost, google stays all the time. all the others i add are lost after closing and reopening though. this happens wether i have typed in the correct path or not (besides this problem only occurs since a few builds... i can't say for sure and i don't want to try out all of them but it happens since somewhere around 0.7.0+...)

Some stuff was recently checked in related to search, so please try a newer trunk build.

No, the real issue is still there. A search engine resource shouldn't depend on the install path.

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

The bug I was referring to is 231203.

I'm not sure where I should post this. But I can confirm that the problem I reported on this bug is fixed in the 2-5-2004 trunk build on Mac OS X.

(In reply to comment #27) I've attached a very simple fix for the exception - basically, it doesn't try to open the file if it is "__PheonixFindInPage" - perhaps it should check if it starts with "engine://"... -[Unknown]

Not a blocker to 0.9. This would be nice to get though. Ben thinks it's not happening as often now. Might slip out to beta or final.

As the reporter of this bug, I also don't think it is a blocker. The problem isn't fixed, but the symptoms are taken care of. In my opinion, we could still get to 1.0 without changing anything in this bug. The only real way to trigger it now, is to change the case of the path either by manually moving the executable or renaming a directory.

+ing for investigation

As already mentioned by someone, bug 187293 is the same for the suite.

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

Not a "blocker"

Pretty sure this no long applies with the new search service, but we'll find out by dropping it in Gavin's lap.

Certainly no longer relevant to the new search service.