620672 - Disappearance of search engine list when using Firefox 4.0 beta releases [caused by testpilot]

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect)

Description

[Dimitri]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

When you click on the button to show the drop down list of all your search engine the list is empty.

Reproducible: Always

Steps to Reproduce:
1. launch firefox in noremote my command line "C:\Program Files\Mozilla Firefox 4.0 Beta 7\firefox.exe" -P firefox4 -no-remote
2. open one page you should have one non empty tab
3. launch an URL with a shellexecute from outside firefox simple way start->run "http://www.mozilla.org/" but works from many other app like IM softwares.

Actual Results:  
the Mozilla website is launched in new windows and the search engine list is empty

Expected Results:  
the Mozilla website is launched and the search engine list is as usual

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Can you please attach the search.sqlite file? Does it also happen in Safe Mode?

Comment 2

[Dimitri]

The bug was 100% reproductible on beta 7 on 2 computers windows 7 and windows xp, but I upgrade to beta 8 before reading my mails. 
I've tried in both both safe and normal mode and the step I gave don't erase the engines in beta 8.
I'll keep that bug updated in the next few days after more real life use and post if I find something or even nothing.

Comment 3

[Damon Sicore (:damons)]

Just hit this at home running beta 8.  It's actually been broken for about a week or so (I'm guessing that it started when the upgrade happened).  The troubling part is that there's no indication, really, that you have no search engines listed.  It's just a blank box.  You can try to search, but nothing happens.  No error.  If the user has no search engines configured and they try to search, there should at least be some indication that the user needs to select a search engine.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Damon, can you please attach the search.sqlite file?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #4)
> Damon, can you please attach the search.sqlite file?

Oh, and we also have bug 593694, which is similar.

Comment 6

[Dimitri]

Attachment: Search.Sqlite before and after the problem

I reproduce the same behaviors on firefox 4 beta 8 on my win XP.

I've backup the search.sqlite before launching an URL from start menu and after.

Comment 7

[Dimitri]

I'm trying to find what happens but failed. 

I'm unable today to find and describe a 100% accurate way to hide search engines.
I used to lose my search engine once or twice a day with beta 7 on both win7 and WinXP. But haven't lost them since updating my win7 to beta 8, and only once on my winxp (the time I upload the search.sqlite)

Guess it will be safer to mark that bug INVALID if no one else find reproducible way.

Here is what I tested with no success
firefox 4 beta 8 use is own profile firefox4
firefox 3.6 use default profile and is default browser

launch v4 -no-remote -P firefox4 open site
launch v3 from sys (default profile)
OK

Make v4 default
launch v4 -no-remote open site (default profile)
launch v4 from sys (default profile)
OK

Make v4 default
launch v4 -no-remote -P firefox4 open site
launch v4 from sys (default profile)
OK

Make V3 default
launch v4 default profile open site
launch v3 from sys (share same profile same time)
OK

I've even tried to use both v4 and v3 with same profile at the same time and except from the module check at start everything work ( pretty amazing btw )

Comment 9

[LegNeato]

Marking as a regression and bumping up the importance due to the input complaints in bug 622658...commonly reported issue in beta 8.

Comment 10

[LegNeato]

FWIW, very similar to bug 593692, which happened between beta 4 and 5 so it might not be new to beta 8.

Comment 11

[Mike Kaply [:mkaply]]

I'm seeing this as well. I even unhid all my engines and it came back (I have it right now).

I do a LOT of switching back and forth between Firefox 4 and 3.6 with the same profile. Not sure if that is helpful.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Really need to figure out some way to reproduce this to make progress. I've tried a couple of upgrade/downgrade/switch scenarios and haven't managed to. Bug 593694 and bug 562612 sound like they could be related, but it's going to be really hard to try figure this out purely from code inspection...

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Michael, do you have a profile you can share with us? Would be good to have an already setup profile which shows this issue. I've also tried various ways in the last hour without success.

Comment 14

[Mike Kaply [:mkaply]]

Unfortunately not. I "fixed" it, and I can't recreate. Should have saved my profile. I'm still trying...

Comment 15

[Mike Kaply [:mkaply]]

The one comment I said to Gavin on IRC that I'll repost here is that I remember switching back to FF 3.6 and I just had Creative Commons and Answers.com, so that would imply that it definitely happened on the Firefox 4 end.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I have found an interesting fact in one of the input messages:

All of the search engines in the search box vanished after the testpilot on search usage submitted data restored defaults and they were back

As far as I have heard about this issue does only occur in beta releases but no-one has seen it in a nighly build, right? So testpilot could have an influence on it.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I have talked with Jono on IRC, and yes there were some search studies. The first one started on Aug 23rd and the second one on Dec 10th. There were five tasks which users have been assigned to randomly:

1. Randly reorder the search engine menu
2. Insert Bing as 2nd choice
3. Insert Bing as last choice
4. insert Twitter as last choice
5. no change

In all cases the search engine list has been saved on start and restored at the end. Therefor the complete list gets wiped out and filled in again. So my assumption is that the restore could somehow be broken.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So the list of engines and their order gets stored in the preference "extensions.testpilot.searchbar_study.originalMenu"

The code is accessible here:
http://hg.mozilla.org/labs/testpilotweb/file/764727afa61c/testcases/search/searchbar-study.js

Not sure if we are on the right track, but lets check the code if we can find something.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So far I wasn't lucky to reproduce it with Testpilot.

Daemon, have you run the search study in December? Can you remember when it has been started? Before the upgrade from b7->b8 or afterward? The default 7 days duration maps perfectly to the b8 release day.

Comment 20

[Mike Kaply [:mkaply]]

I was thinking about this and the one unique thing about my scenario at least is that I have a non default Bing installed.

Perhaps the problems related to the fact that the search study code (at least as I read it) assumes that only the default Firefox Bing is installed.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Updating summary, to better reflect that this bug only hits users who run beta versions of Firefox 4.0. And it didn't only happen for Beta 7.

Comment 23

[:Gavin Sharp [email: [e-mail]]]

I reviewed the test pilot study code more closely and found this:
http://hg.mozilla.org/labs/testpilotweb/file/9794778f6475/testcases/search/searchbar-study.js#l364

If the pref used to save the previous state is somehow cleared, or if writing/reading/parsing it fails for whatever reason, the cleanup for the test pilot study will remove all engines, which would result in the symptoms described here.

Thankfully it seems like there's an easy way to check whether this study was run, which could help give an indication of whether this theory is correct:

1) Open about:config
2) Enter "extensions.testpilot.taskStatus." in the "filter" field
3) Look for either "extensions.testpilot.taskStatus.13" or "extensions.testpilot.taskStatus.8" entries in the resulting list.
3) If either (or both) exist, note their value (should be a number)

Can everyone who's seen this bug can follow those steps and post their results here?

Comment 24

[Frédéric Buclin]

extensions.testpilot.taskStatus.8 = 9

Comment 25

[My]

extensions.testpilot.taskstatus.13 = 6
extensions.testpilot.taskstatus.8 = 6

Comment 26

[Mike Kaply [:mkaply]]

extensions.testpilot.taskstatus.8 = 9
extensions.testpilot.taskstatus.13 =4

Comment 27

[Melissa Shapiro [:shappy]]

extensions.testpilot.taskstatus.8 = 8
extensions.testpilot.taskstatus.13 =6

Comment 28

[Frédéric Buclin]

What are the right numbers to win $1,000,000?? :-p

Comment 29

[:Gavin Sharp [email: [e-mail]]]

OK, that's a pretty good indicator that test pilot is involved here. Another interesting data point would be someone who's seeing this issue who *doesn't* have those prefs set.

Comment 30

[Jono Xia]

Hi everybody.

After IRC discussion with Gavin yesterday about this bug, I decided to take down the search study since it seems likely that it's contributing to this bug.  We already got the data we wanted, so there's no good reason to keep it up.

Taking it down means that it is not being deployed to any additional users, but users who are already running the study will finish running it.

Since the bug that clears the menu appears to happen at the end of the study, that means that some of these users may experience the bug when their copy of Test Pilot finishes the study.  Since the duration of the study was set to 7 days, all users still running the study will finish it by Jan. 17.  If the study is indeed responsible for the bug, as seems likely, this means that after Jan 17, we shouldn't see this bug happen anymore.

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Jono! I assume that also means that no users with Beta 9 (or a candidate build) will get this study from now on?

Removing the regression keywords because those don't seem to be necessary here.

Comment 32

[Jono Xia]

Henrik: No users will get the study after Jan 10 (yesterday), regardless of what beta version they have.

Deployment of studies is generally independent of beta releases - a study can specify a range of Firefox versions on which it will run, but other than that, studies doesn't care what beta you're on.

Comment 33

[:Gavin Sharp [email: [e-mail]]]

I wish I understood the exact failure case a little bit better here, but every indication we have is that the people seeing this all ran the search test pilot study, so given comment 23-comment 30, I think we can mark this WORKSFORME/FIXED (by removing the study).

Comment 34

[Chris AtLee [:catlee]]

I ran into this on my wife's Vista machine.  She was running 4.0b8, with two profiles: "default", and my profile.  Both are running test pilot.

After updating to 4.0b9, my profile lost all of its search engines.  The "default" profile was fine.  Going to "Manage search engines" -> "Restore defaults" restored them for me.

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Chris, does it mean it only happened for the profile which has been used for upgrading to b9? The other profile doesn't show it when it gets run with b9?

Comment 36

[Chris AtLee [:catlee]]

(In reply to comment #35)
> Chris, does it mean it only happened for the profile which has been used for
> upgrading to b9? The other profile doesn't show it when it gets run with b9?

I used the default profile to update to b9.