Closed Bug 205708 Opened 21 years ago Closed 18 years ago

search toolbar forgets engine if called from path with wrong case

Categories

(Firefox :: Search, defect, P2)

Product:
Firefox
Component:
Search
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mikegoodspeed, Unassigned)

References

Details

Attachments

(2 files)

temporary fix.
1.12 KB, patch
Details | Diff | Splinter Review
exception fix from previous.
674 bytes, patch
Details | Diff | Splinter Review 
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.
Summary: search bar forgets engine if I start with a URL parameter. → search toolbar forgets engine if called from path with wrong case
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
QA Contact: asa → bugzilla
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.
Assignee: hyatt → p_ch
bug still occurs in 20031208
Flags: blocking0.8?
*** Bug 228954 has been marked as a duplicate of this bug. ***
pierre, any chance of fixing this before 0.8?
Flags: blocking0.8? → blocking0.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
Flags: blocking0.8- → blocking0.8+
Priority: -- → P2
Target Milestone: --- → Firebird0.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
Target Milestone: Firebird0.8 → Firebird0.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)
Flags: blocking0.9?
Flags: blocking0.8-
Flags: blocking0.8+
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.
Flags: blocking0.9? → blocking0.9-
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.
Flags: blocking1.0?
+ing for investigation
Flags: blocking1.0? → blocking1.0+
As already mentioned by someone, bug 187293 is the same for the suite.
Target Milestone: Firefox0.9 → Firefox1.0beta
*** Bug 248660 has been marked as a duplicate of this bug. ***
Assignee: p_ch → sspitzer
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0RC1+ → blocking-aviary1.0RC1-
Flags: blocking0.9-
Flags: blocking0.8-
Not a "blocker"
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
QA Contact: bugzilla → toolbars
Pretty sure this no long applies with the new search service, but we'll find out by dropping it in Gavin's lap.
Assignee: sspitzer → nobody
Component: Toolbars → Search
QA Contact: toolbars → search
Target Milestone: Firefox1.0beta → ---
Certainly no longer relevant to the new search service.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: