Closed Bug 108043 Opened 23 years ago Closed 14 years ago

Regression: search/smart browsing prefs forgotten

Categories

(Core :: Preferences: Backend, defect)

Product:
Core
Component:
Preferences: Backend
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: akkzilla, Assigned: samir_bugzilla)

Details

(Keywords: qawanted, regression)

In the last week, I've had several instances where the browser forgets my search and smart browsing preferences, and goes back to searching netscape.com and turning on internet keywords, and I have to go change them all back again. Timeless suggested that this might have something to do with switching back and forth between netscape and mozilla builds, which of course I do in the normal course of my job. It's possible it's a bugscape bug, but I suspect not since the infrastructure shouldn't ignore already-set preferences in any case. This is a recent regression, introduced in the past week or so.
Keywords: regression
->samir?
Assignee: bnesse → sgehani
QA Contact: sairuh → claudius
Please verify this with a current build. Over the past week there was some bustage in the preferences support as it pertained to the search panel... not certain about smart browsing.
Can't reproduce on Win2K or Linux. Used today's mozilla opt build on Win2K and today's netscape opt build on Linux. The browser remembered my internet keywords enabled pref, default search engine pref, and search mode pref between browser sessions.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
This has happened to me twice now, once with a build from yesterday, once with a build from a few days ago (Monday?) Both LInux. I don't know what causes it. Generally I use an opt build for browsing and bring up my debug build for testing things (mostly in editor and browser). Maybe related to running them simultaeously?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
>Maybe related to running them simultaeously? Eeeeek !!! :) Prefs.js is most definitely NOT multisession aware. If you have 2 sessions open at the same time, the last one closed will win...
This has worked fine for many months, until this week. It's a recent change. (Multiple sessions are not something I can avoid, unless I stop using our browser for dogfood and go back to 4.x or some other browser.) I'm not changing any prefs myself; something in the app is changing them for me. Understood that the last one closed will win, because the locking we had in 4.x hasn't been implemented yet in mozilla; but that's not the problem here, since I never intentionally change these prefs. I'll try today's build if I can find a respin from after the blockers got fixed. (It's been hard this week to find builds that are usable at all ...)
This isn't very recent. My search engine has been getting reset from google to NS for 6+ months. I've filed a seperate bug on that somewhere. It seems related to installing new mozilla builds. Never seen NS keywords flip back on.
It comes and goes; I hadn't seen it for a long time, but it just showed up again and now is doing it pretty consistently. (Or was last week; I haven't been using dailies this week because they've all had serious blockers.)
Today the search engine <select> is complely blank, and searching isn't working at all.
Yeah, I noticed that search-panel.js is throwing a whole bunch of new JS warnings/errors to the console on today's mac build... And I just finished cleaning up the last batch. :(
See also 108543
Akkana, i have 2 profiles on windows, one is named WinEmbed, and it has my mail, another is named Default, and it has virtually nothing. I run a Mozilla build and a Netscape build attached to each of those profiles, (randomly picking which goes where depending on how rotten a current mozilla build is). I've done similar things for mozilla on linux, except that i have 3+ homedirs and each of them has their own set of profiles, this enables me to avoid prefs.js sharing while having multiple concurrent mozilla instances. As for the actual bug here, um, i just suffer from bug 108543.
Akkana, something was just brought to my attention... do you launch using -p ? And, since this has now forked into Search doesn't work at all... It appears that the syntax at line 198 in search-panel.js: var basicEngines = basicEngineMenu.childNodes[1]; is no longer valid. It appears that .firstChild is the right way to go, but I don't know enough XUL to carry me to a solution... just more errors :(
Brian, Search works for me in today's build. Is there a bug on "search doesn't work at all" for some other platform? The only glaring search bug I see is bug 109143. Are you using strict mode to see the bunch of warnings/errors you describe?
I don't launch with -p. I only have one profile, and I typically either run "mozilla" with no arguments, or "mozilla -edit" (or, occasionally, add a url after one or another of those commands).
Samir, yes that's exactly what I'm seeing. I will note my info over there. Akkana, ok, nix that. I just found out yesterday that there's a bug with the prefs not being read in correctly when the -p option was used (bug 108383). I figured it could be the source of your problem.
this should be working now. Samir?
I can't reproduce this, but I don't dispute that others may be seeing this. Until we get a reproducible testcase so I can figure out the problem I can't fix it.
Target Milestone: --- → Future
I saw this again yesterday, but I still have no idea what causes it.
I'm using the win installer and my pref is just plain empty. No engines listed in the dropdown. And I dont have any "searchplugins" folder either. Shouldn't there be a subfolder of mozilla.org\mozilla called "searchplugins" ? Could be due to check in made to: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpinstall/packager/windows/regus.jst check: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpinstall/packager/windows&command=DIFF_FRAMESET&file=regus.jst&rev2=1.5&rev1=1.4
Henrik, That's bug 125820.
There where some changes back on 12-04 - 12-10 timeframe where prefs where having issues with read/writing "True" & "False" & checked values correctly.. then was ironed out.. I've seen since this time of early december, many changes have occured with checked/unchecked preferences. Other changes to prefs occur with cleanup of un-used prefs.. and turbo/QL changes so we cannot run two instances, clicking on the mozilla icon now brings up another browser window + add to that the changes to SMAPI where Mozilla now is recognized as a seperate app than Netscape. So with all this: this should be working correctly as fixed in a latest nightly.. So Latest builds should not be having any issues.. and I notice too that no comments have been made after this time frame.. so it looks like this is finally fixed. if so, It looks like we can close this one.
I've noticed that the default search-engine preference is often ignored if a new tab is opened and the search button is clicked. Netscape search gets called up instead of Google, which is what I have set in my preferences.
I saw this so often that I finally got tired of resetting it, and moved my search preference from prefs.js into user.js where it will always override prefs.js. Haven't seen it since then. So that's a workaround, to those who are irritated by this bug.
I've never noticed yet that my search preferences are actually getting unset--they just seem to be ignored. I've played around with this found this and found it to be quite inconsistent... Sometimes the button works and sometimes it stops working. Then sometimes it seems to start working again after having stopped working. To get around it, I just made my own Google link button under the URL bar :)
This happens to me all the time on Windows (changed OS to All.) Using N70PR1 (I tried the same thing on the mozilla1.1a build, but had no problems.) Steps to recreate: - Go to prefs and change search from Netscape to Google. - Exit browser, make sure you exit Quick Launch too, otherwise the prefs stay put. - Start browser again and return to prefs . -- Now search is re-set to Netscape. In windows, I'm not having the same problems with Smart Browsing, only with Search Options.
OS: Linux → All
I suggest someone tries to reproduce this on a recent _Mozilla_ build. janc: > Using N70PR1 (I tried the same thing on the mozilla1.1a build, but had no > problems.) well then it's a problem for Bugscape.
I can't reproduce this bug nowadays. Suggest marking worksforme.
marking w4m --akkana, is this still a problem for you with a recent build?
QA Contact: claudius → sairuh
really marking.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
I gave up long ago and put the pref in user.js so it wouldn't get stomped. I occasionally see other people complain about this. It's probably related to other known profile problems, e.g. mixing NS and moz profiles.
this is not working. Sometimes I have to reset the search pref to google. it always gets reset to netscape. I'm *always* running nightly build, so no profile corruption here. Never had netscape installed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I agree... I just noticed that using a new build (2003030305) has reset my search pref again to Netscape search. Occasionally a new build will do this, while most don't.
I am experiencing this bug with 1.5beta using build ID 2003082703 using MacOS X 10.1.5. Mozilla is unable to remember which search engines I have set to use in the sidebar and resets to use Netscape Search as a default. Steps to reproduce 1. Select Search in the sidebar 2. Select a group of search engines to use. 3. Select Bookmarks from the sidebar 4. Select Search again from the sidebar 5. Notice all the search engine previously selected are now unselected. It appears as if Mozilla is set to save the search preferences when another sidebar panel is selected after using the sidebar search panel (this is my guess). In any case, the sidebar search preferences fail to be saved when either switching to another sidebar panel or quiting the Mozilla application. This bug is annoying and I would love a fix. ;)
QA Contact: bugzilla → preferences-backend
Status: REOPENED → RESOLVED
Closed: 22 years ago → 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.