Regression: search/smart browsing prefs forgotten




18 years ago
8 years ago


(Reporter: akkzilla, Assigned: samir_bugzilla)


({qawanted, regression})

qawanted, regression

Firefox Tracking Flags

(Not tracked)




18 years ago
In the last week, I've had several instances where the browser forgets my search
and smart browsing preferences, and goes back to searching 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.


18 years ago
Keywords: regression
Assignee: bnesse → sgehani
QA Contact: sairuh → claudius

Comment 2

18 years ago
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.

Comment 3

18 years ago
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.  
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 4

18 years ago
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?
Resolution: WORKSFORME → ---

Comment 5

18 years ago
>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...

Comment 6

18 years ago
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 ...)

Comment 7

18 years ago
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.

Comment 8

18 years ago
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.)

Comment 9

18 years ago
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. :(

Comment 11

18 years ago
See also 108543

Comment 12

18 years ago
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 :(

Comment 14

18 years ago
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?

Comment 15

18 years ago
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?

Comment 18

17 years ago
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
Target Milestone: --- → Future

Comment 19

17 years ago
I saw this again yesterday, but I still have no idea what causes it.

Comment 20

17 years ago
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 called "searchplugins" ?

Could be due to check in made to:

Comment 21

17 years ago
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

if so, It looks like we can close this one.

Comment 23

17 years ago
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.

Comment 24

17 years ago
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.

Comment 25

17 years ago
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 :)

Comment 26

17 years ago
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.
> Using N70PR1 (I tried the same thing on the mozilla1.1a build, but had no
> problems.)

well then it's a problem for Bugscape.

Comment 28

16 years ago
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.
Last Resolved: 18 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 31

16 years ago
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.

Comment 32

16 years ago
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.
Resolution: WORKSFORME → ---

Comment 33

16 years ago
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.
Keywords: qawanted

Comment 34

16 years ago
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
Last Resolved: 16 years ago8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.