User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.4) Gecko/20030624 I have a PGPdisk which houses my Mozilla profile; my version of a roaming profile. In my prefs, my default search engine is set for Google. Whenever I move my profile (via ZIP disk) to another computer and click on the "Search" button, the Netscape search engine always appears. Double-checking my prefs, it's set back to Netscape. After "resetting" it back to Google, it works fine for that computer. Move the profile (folder and all files) to another computer, back to Netscape. Wondering if it's a registry setting? Reproducible: Always Steps to Reproduce: 1. Create profile on a removeable disk 2. Set up search preferences on 1st computer 3. Close browser and move disk to another computer 4. Try search again. Actual Results: My prefered search engine goes from Google back Netscape Expected Results: Stayed with Google.
This can happen if you use different Mozilla versions with that profile. Is this true ?
Maybe? I wouldnt know since I always used the same version of Mozilla with the same profile.
dupe of bug 206464?
I don't thing that's dupe of bug 206464, unless it means exactly the same as search preferences. However this seems to me as dupe of bug 208894.
Similar to bug 208894, but not. We're not talking about an upgrade of Mozilla. See my 2nd post where I stated it's the same version of Mozilla. 1) Mozilla 1.4 is installed on Computer A. 2) Profile is created on a PGP-disk on a 100 MB ZIP disk. a) Profile is setup to use Google as default search engine. 3) Close PGP-disk. Remove ZIP disk. 4) Mozilla 1.4 is installed on Computer B. 5) Insert ZIP disk, mount PGP-disk (same volume letter as Computer A) 6) Create a profile on Mozilla (computer B) to look at PGP-disk 7) Press the SEARCH button ..... and get Netscape instead of Google. Definitely not a dupe of bug 206464
Birl: I think the point is that the Mozilla application directory is different on the different computers. Whether this happens because of an upgrade or the move to a different computer, does not matter. The problem is that the search engine is saved in the preferences as an absolute path to your Mozilla application directory (see the pref "browser.search.defaultengine" after entering "about:config" in your URLbar). Maybe you could test this assumption by ensuring that Mozilla is called in exactly the same directory (even capitalization seems to matter!) on two different computers and then looking if Mozilla still forgets your search engine. Further reading: bug 205708 comment #16, and bug 212207 comment #11 and 12.
Good theory; tested that long ago; failure. My prefs.js file is manually coded with the following. user_pref("browser.search.defaultengine", "engine://N%3A%5Csbirl%5Csearchplugins%5Cgoogle.src"); I even went so far as to put that code in the read-only user.js file. No dice. The N:\ drive is consistant on every computer as it is the location of the PGPdisk when mounted. Search engine has been known to default back to Netscape. First, my comment on bug 212207 comment #12: I did go so far as to copy the searchprofile directory from the application folder into the profile directory. The Mozilla binary, was not copied into the profile directory. I see no point in having more than 1 binary on the computer. I think I can understand what you are refering to in bug 205708 comment #16. But my question is this: Wouldnt "engine:///" merely be a shorthand for a absolute path name? I would assume that "engine:///" would have to point to somewhere tangible on the hard drive in order to read/execute google.src AFAIK, "engine:///" is not defined in the preferences, therefore each installation of Mozilla would have to know where "engine:///" points to. My comment on bug 212207 comment #11: "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" But the serach engine *is* explicitly set, even before I changed it to point to the N:\ drive. Unless of course "explicitly set" means the search engine points to a physical location on the hard drive, then the original preference using "engine:///" was not explicitly set. Please correct me if Im misunderstanding something. Thanks.
S.A. Birl: > Wouldnt "engine:///" merely be a shorthand for a absolute path name? No this is a kind of protocol descriptor, the absolute path follows afterwards. This looks very much like bug 187293... Could you please: 1) provoke the situation this bug is about (i.e. make it so the search engine reverts to Netscape or whatever) 2) type "about:config" into your location bar 3) find the pref "browser.search.defaultengine" (e.g. type "search.default" into the filter field to find it easier) 4) right-click on that pref and "Copy Value" and paste it into this bug 5) set your search engine to be Google 6) repeat steps 2)-4) 7) Submit bug comment ;-) Thanks!
NEW: S.A.: Andreas is right. Your engine: URL is not going to work, you would need, at minimum, 3 slashes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: chrispetersen → benc
(In reply to comment #8) > S.A. Birl: > > Wouldnt "engine:///" merely be a shorthand for a absolute path name? > > No this is a kind of protocol descriptor, the absolute path follows afterwards. Got it. > This looks very much like bug 187293... Similar but not the same as bug 187293 That bug says it lasts for the current session. This *was* not a session issue. It was a profile issue. I say *was* because since version 1.6 this no longer seems to be an issue. Im running 1.7 now If, by chance, this occurs again, then maybe I'll attempt to reproduce it using the steps in Comment #8. In the meantime, I will change the resolution to FIXED. Thanks.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
No fix specified. ->WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.