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

RESOLVED WORKSFORME

Status

()

Firefox
Search
--
major
RESOLVED WORKSFORME
7 years ago
7 years ago

People

(Reporter: Dimitri, Assigned: Gavin)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [hardblocker])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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
Can you please attach the search.sqlite file? Does it also happen in Safe Mode?
(Reporter)

Comment 2

7 years ago
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.
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.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Damon, can you please attach the search.sqlite file?
(In reply to comment #4)
> Damon, can you please attach the search.sqlite file?

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

Comment 6

7 years ago
Created attachment 500351 [details]
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.
blocking2.0: ? → betaN+
(Reporter)

Comment 7

7 years ago
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 )
Summary: Disappearance of search engine list in ff4 b7 (reproducible) → Disappearance of search engine list in ff4 b7
Duplicate of this bug: 622658

Comment 9

7 years ago
Marking as a regression and bumping up the importance due to the input complaints in bug 622658...commonly reported issue in beta 8.
Severity: normal → major
Keywords: regression

Comment 10

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

Updated

7 years ago
Keywords: regressionwindow-wanted
Whiteboard: [Input]
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.
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...
Keywords: qawanted
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.
Unfortunately not. I "fixed" it, and I can't recreate. Should have saved my profile. I'm still trying...
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.
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.
OS: Windows XP → All
Hardware: x86 → All
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.
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.
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.
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.

Updated

7 years ago
Version: unspecified → Trunk
Whiteboard: [Input] → [Testpilot?]
Duplicate of this bug: 593692
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.
Summary: Disappearance of search engine list in ff4 b7 → Disappearance of search engine list when using Firefox 4.0 beta releases
Assignee: nobody → gavin.sharp
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

7 years ago
extensions.testpilot.taskStatus.8 = 9

Comment 25

7 years ago
extensions.testpilot.taskstatus.13 = 6
extensions.testpilot.taskstatus.8 = 6
extensions.testpilot.taskstatus.8 = 9
extensions.testpilot.taskstatus.13 =4
extensions.testpilot.taskstatus.8 = 8
extensions.testpilot.taskstatus.13 =6

Comment 28

7 years ago
What are the right numbers to win $1,000,000?? :-p
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.
Blocks: 593694
Blocks: 620318
Blocks: 593692
Blocks: 622658

Comment 30

7 years ago
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.
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.
Keywords: regression, regressionwindow-wanted

Comment 32

7 years ago
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.
Whiteboard: [Testpilot?] → [Testpilot?][hardblocker]
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).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Summary: Disappearance of search engine list when using Firefox 4.0 beta releases → Disappearance of search engine list when using Firefox 4.0 beta releases [caused by testpilot]
Whiteboard: [Testpilot?][hardblocker] → [hardblocker]
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.
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?
(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.
You need to log in before you can comment on or make changes to this bug.