866254 - Starting firefox with search windows not working / issues at about:home in Private Browsing mode

Status: RESOLVED FIXED

(Firefox :: Search, defect)

Description

[Michel]

Attachment: Firefox bug.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130326150557

Steps to reproduce:

when starting firefox 20.0 on my mybook pro os 10.7.5 and after typing any search item in the search window and pressing search button ... no action/answer.


Actual results:

nothings


Expected results:

the search engine should have started and propose me severals web page links

Comment 1

[Matthias Versen [:Matti]]

Does it work in the Firefox safemode ?
http://support.mozilla.org/en-US/kb/Safe+Mode

Comment 2

[Maria Grazia Alastra [:mga]]

This bug happens also on Windows 7 x64.
It happens on safe mode, but not with a clean profile.
Specifically, I tested it with Firefox 21.0, User Agent Mozilla/5.0 (Windows NT
6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0, Build ID 20130425162858.

The bug is reproducible all the way back until 20.0.1, and it was introduced by the Nightly build of 23 December 2012, 06:50. User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:20.0) Gecko/20121223 Firefox/20.0 Build ID 20121223030832.

Here is the list of changes made before that Nightly release: https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-12-22+04%3A50&enddate=2012-12-23+06%3A53

Also, bug 817104 might be related, but I'm not sure.

Steps to reproduce:

- From your default profile go to Options -> Privacy and select "never remember history" (you can see also in the screenshot provided by Michel that he was in Private Browsing mode.

- Restart Firefox.

- In about:home type something in the search bar under the Firefox icon and click on "Search".

Actual results: no action is performed.

Expected results: a search should be performed.

I also report that the "Google" writing on the left of the search bar is not displayed anymore from the default profile, but in the previous versions of Firefox, and also on the Nightly right before the one that introduced the bug, it is displayed.

Comment 3

[Alice0775 White]

Error in error console:

Error: DEPRECATION WARNING: Search service falling back to deprecated synchronous initializer.
You may find more details about this deprecation at: https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIBrowserSearchService#async_warning
resource://gre/components/nsSearchService.js 3850 epsSyncInit
resource://gre/components/nsSearchService.js 2589 SRCH_SVC__ensureInitialized
resource://gre/components/nsSearchService.js 3557 null
resource://app/modules/AboutHomeUtils.jsm 26 null
chrome://browser/content/browser.js 10456 BrowserOnAboutPageLoad
chrome://browser/content/browser.js 12406 TabsProgressListener.onStateChange
chrome://browser/content/tabbrowser.xml 413 null
chrome://browser/content/tabbrowser.xml 410 _callProgressListeners
chrome://browser/content/tabbrowser.xml 457 ._callProgressListeners
chrome://browser/content/tabbrowser.xml 618 .onStateChange
null 0 null

Source File: resource://gre/modules/Deprecated.jsm
Line: 79


Error: [Exception... "'Error: Internal error: invalid state FINISHED_SUCCESS' when calling method: [nsIBrowserSearchService::defaultEngine]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "JS frame :: resource://app/modules/AboutHomeUtils.jsm :: <TOP_LEVEL> :: line 26"  data: no]
Source File: chrome://browser/content/tabbrowser.xml
Line: 417

Comment 4

[Maria Grazia Alastra [:mga]]

From the error message posted by Alice, I think the following change might have caused (part of?) the problem: https://hg.mozilla.org/mozilla-central/rev/98dddd0da122

However I'm new to Mozilla, so I can certainly be wrong.

Comment 5

[(no longer active)]

Gavin, can you imagine what's going on here?

Comment 6

[Alice0775 White]

Please ignore comment #3, because this bug is for Firefox 64bit build.

I cannot reproduce in Firefox20.0.1 32bit build on Wndows7 x64.
However I can reproduce in Firerox21.b6 32bit build on Wndows7 x64.

I am not sure that the root cause is different or same.
Anyway I will file a Bug 868595 for 32bit build Firefox.

Comment 7

[Alice0775 White]

(In reply to Maria Grazia Alastra [:mga] from comment #4)
> From the error message posted by Alice, I think the following change might
> have caused (part of?) the problem:
> https://hg.mozilla.org/mozilla-central/rev/98dddd0da122
> 
> However I'm new to Mozilla, so I can certainly be wrong.

Sorry spam, 
Please ignore comment #3

Comment 8

[Alice0775 White]

From Comment 2
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf26f61a0748&tochange=84320dffec6e

Comment 9

[Maria Grazia Alastra [:mga]]

Attachment: (PB not enabled) Screenshot of the about:home page running a Greasemonkey script which retrieves the value of "searchEngineName"

When Firefox isn't in Private Browsing mode, the value of searchEngineName in about:home is normally retrieved, as expected.

Comment 10

[Maria Grazia Alastra [:mga]]

Attachment: (PB enabled) Screenshot of the about:home page running a Greasemonkey script which retrieves the value of "searchEngineName" (in this case "null")

However, when Firefox *is* in Private Browsing mode, the value of searchEngineName in about:home becomes "null".

This means that when in permanent Private Browsing mode, the name of the predefined search engine is, somehow, erased or hidden.

I'd like to point to you the function setupSearchEngine() from aboutHome.js (http://mxr.mozilla.org/mozilla-central/source/browser/base/content/abouthome/aboutHome.js#257).

You can see that after the function retrieves the value of searchEngineName, it also uses this value to access the corrispondent position in SEARCH_ENGINES and assign it to the variable searchEngineInfo.

After this, if and only if searchEngineInfo and searchEngineInfo.image exist, the "Google" logo is displayed on the left of the search bar.

So, given that in PB the value of searchEngineName is null, searchEngineInfo will also be null, and this is why the logo isn't displayed when the bug is reproduced.

Comment 11

[Maria Grazia Alastra [:mga]]

I've also tried to retrieve the value of searchEngineURL using the same Greasemonkey script, only substituting "searchEngineName" with "searchEngineURL" and of course the value is normally retrieved when PB is not enabled, but it's null when it is enabled.

So, given that searchEngineURL must not be null to perform a search action (aboutHome.js, function onSearchSubmit(aEvent): http://mxr.mozilla.org/mozilla-central/source/browser/base/content/abouthome/aboutHome.js#230), that's why it isn't performed in PB.


Recap: in PB searchEngineName and searchEngineURL are both null, and this means that the search cannot be performed and the Google logo can't be displayed on the left of the search bar in about:home.

Now the problem is finding the piece of code in which PB accidentally hides/erases these values. Thank you for your attention, and sorry for the three consecutive posts.

Comment 13

[(no longer active)]

David, can you please take a look at this?  It would be a shame if we ship this regression in Firefox 21.

Comment 14

[David Teller [:Yoric] - still alive but not very active]

I will take a look.
The deprecation warning is (probably) normal, until bug 789348 lands.
The error, of course, isn't.

Comment 15

[David Teller [:Yoric] - still alive but not very active]

Attachment: Experimental patch

Comment 16

[David Teller [:Yoric] - still alive but not very active]

Can someone test with the patch?

Comment 17

[Maria Grazia Alastra [:mga]]

(In reply to David Rajchenbach Teller [:Yoric] from comment #16)
> Can someone test with the patch?

I was willing to test this patch on Ubuntu 12.04, but first I checked if the bug is reproducible here and I wasn't able to reproduce it. That's weird.

User agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 (Build ID: 20130430204233)

Comment 18

[David Teller [:Yoric] - still alive but not very active]

Applying the steps of comment 2 under MacOS X, patch works for me.

Comment 19

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

Ideally, I would like to better understand why this is happening before we just wallpaper over the error.

Comment 20

[Maria Grazia Alastra [:mga]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #19)
> Ideally, I would like to better understand why this is happening before we
> just wallpaper over the error.

If it can help you, I think the reason why I wasn't able to reproduce the bug on Ubuntu might be that my default profile there is almost clean, or at least way cleaner than the one on Windows. However to be sure this bug should be tested there (or on any Linux distribution, probably) by someone which uses it everyday, from quite a bit of time.

Oh, and I get quite a bit of errors in Error console when I open Firefox on Windows 7 (User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0, Build ID 20130409194949)(my starting page is about:home):

"Error: this.docShell is null
Source File: chrome://global/content/bindings/browser.xml
Line: 323"

"Error: gBrowser.addProgressListener was called with a second argument, which is not supported. See bug 608628.
Source File: chrome://browser/content/tabbrowser.xml
Line: 1999"

"SessionStartup: _ensureInitialized: null" (4 times)

"Error: [Exception... "'Error: Internal error: invalid state FINISHED_SUCCESS' when calling method: [nsIBrowserSearchService::originalDefaultEngine]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "JS frame :: resource://gre/modules/AboutHomeUtils.jsm :: <TOP_LEVEL> :: line 25"  data: no]
Source File: chrome://browser/content/tabbrowser.xml"
Line: 404

"Error: no element found
Source File: https://testpilot.mozillalabs.com/testcases/index.json
Line: 1"

If I clear the console and reload the about:home page I get only one error, though, which is the following:

"Error: AboutHomeUtils.defaultSearchEngine is undefined
Source File: chrome://browser/content/browser.js
Line: 9820"

I saw this only today, because I have the developer toolbar always opened and I thought that if there were errors I'd saw the red square with the number of errors in it. Hope it helps somehow.

I'm available for further testing, if needed. I would like to understand a bit more about this bug, too.

Comment 21

[[:Aleksej]]

This bug doesn't happen for me with Firefox 21.0 Beta on Debian GNU/Linux 7.0.

Comment 22

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

(In reply to Maria Grazia Alastra [:mga] from comment #20)
> Oh, and I get quite a bit of errors in Error console when I open Firefox on
> Windows 7 (User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0)
> Gecko/20100101 Firefox/20.0, Build ID 20130409194949)(my starting page is
> about:home):

> "Error: [Exception... "'Error: Internal error: invalid state
> FINISHED_SUCCESS' when calling method:

All of those errors are caused by this one, essentially. What's needed is a reliable way for Yoric or I to reproduce this problem, starting with a blank profile. Do you have any ideas on what in your profile might be causing this, if not add-ons (since comment 2 suggests it happens in safe mode)?

Comment 23

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

There may be a race condition involved, which could also explain the difficulty in reproducing this.

Comment 24

[David Teller [:Yoric] - still alive but not very active]

Attachment: Printing out more details (DO NOT LAND)

I will resume investigation tomorrow.
In the meantime, here is an (untested) patch that should display more information whenever we change the offending state. This might help us track down why that state changes in an unexpected manner.

Comment 25

[Maria Grazia Alastra [:mga]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #22) 
> All of those errors are caused by this one, essentially. What's needed is a
> reliable way for Yoric or I to reproduce this problem, starting with a blank
> profile. Do you have any ideas on what in your profile might be causing
> this, if not add-ons (since comment 2 suggests it happens in safe mode)?

I don't think it's just my profile: Michel, the reporter, didn't specify either to start with a clean profile, and, as you said, I tested it in safe mode to ensure it wasn't some add-on's fault. I don't have fancy user preferences, either, and it's not an update issue because the bug is still reproducible after a fresh install of Firefox.

What I thought, but since I'm no expert of your code I'm probably wrong, is that maybe private browsing messes up with user preferences related to browsers? Is it even possible? From Yoric's patch I got the idea, instead, that it may be a loading problem, if I'm not mistaken. Something like that the page loads before searchEngineName and searchEngineURL are set. But that doesn't explain why it happens only in private browsing mode.
I don't really know, but during these days I'm trying to figure out where and how Firefox stores the search engine's related informations. Unfortunately, and you'll  know way better than me, there are search related files and private browsing related code pretty much everywhere in Mozilla's source. And, I'll repeat it, unfortunately I'm very new here.

Comment 26

[Maria Grazia Alastra [:mga]]

(In reply to Maria Grazia Alastra [:mga] from comment #25)maybe private browsing messes up with user preferences related to
> browsers?

I meant "related to search engines", sorry.

Comment 27

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

Hey, good news - I can reproduce this.

(Yoric: that patch is empty)

Comment 28

[Maria Grazia Alastra [:mga]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #27)
> Hey, good news - I can reproduce this.

On a clean profile?

Comment 29

[David Teller [:Yoric] - still alive but not very active]

Attachment: Printing out more details (DO NOT LAND)

Sorry about that.

Comment 30

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

Attachment: fix

After debugging this locally, I think I found the core issue: epsInit fails to return after it successfully loads the JSON file in its first step. And so we fall into the JSON_LOADING_ATTEMPTED branch and then try to migrate the sqlite DB.

I'm not yet able to fully explain why this isn't always a problem. I could reproduce this in my old test profile after enabling "never remember history" (a.k.a. permanent private browsing mode). My old profile also had a search.sqlite file from back when those existed, which affects the timing of _asyncMigrateOldDB.

Comment 31

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

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #30)
> I'm not yet able to fully explain why this isn't always a problem. I could
> reproduce this in my old test profile after enabling "never remember
> history" (a.k.a. permanent private browsing mode). My old profile also had a
> search.sqlite file from back when those existed, which affects the timing of
> _asyncMigrateOldDB.

So I think the explanation is that this combination impacts timing just right, such that epsSyncInit (called via about:home loading in the browser, via the AboutHomeUtils.defaultSearchEngine getter in BrowserOnAboutPageLoad) runs after epsInit has succeeded (setting _initState to FINISHED_SUCCESS), but before the rest of async initialization (checking for the DB to migrate, etc.) has completed. With the patch, the async initialization (triggered by the search.xml constructor, probably?) is shortened, and therefore completes before the about:home load, and so we never hit the _ensureInitialized (and thus epsSyncInit) path.

Comment 32

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

Attachment: fix

Comment 33

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

Attachment: followup logging/cleanup

I removed a redundant Deprecated.warning (engine meta data service is an internal implementation detail, it doesn't need its own warning), and adjust some LOGs to be more consistent in their content and more complete (they helped in identifying the problem here). Also fixed indentation in _asyncMigrateOldDB.

Comment 34

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

We should try to get this into 22, at least, I think.

Comment 35

[David Teller [:Yoric] - still alive but not very active]

Comment on attachment 746118 [details] [diff] [review]
fix

Review of attachment 746118 [details] [diff] [review]:
-----------------------------------------------------------------

Well done, that seems to be the issue.

Comment 36

[David Teller [:Yoric] - still alive but not very active]

Comment on attachment 746129 [details] [diff] [review]
followup logging/cleanup

Review of attachment 746129 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/search/nsSearchService.js
@@ +3839,5 @@
>  
>            default:
> +            throw new Error("metadata init: invalid state " + this._initState);
> +        }
> +        LOG("metadata init: starting");

You probably meant "complete."

@@ +4059,5 @@
> +              store[engine][name] = value;
> +            }
> +          }
> +        );
> +      } catch(ex) {

Could you take the opportunity to change this to |catch (ex)| (with the whitespace)?

@@ +4067,5 @@
> +        sqliteDb.asyncClose();
> +      }
> +      throw new Task.Result(store);
> +    });
> +  },

I'm not sure I understand the point of your changes here, but if you want.

Comment 37

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/cd020c8432e6
https://hg.mozilla.org/integration/mozilla-inbound/rev/d95ddf1d37b0

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/cd020c8432e6
https://hg.mozilla.org/mozilla-central/rev/d95ddf1d37b0

Comment 39

[Maria Grazia Alastra [:mga]]

Verified as fixed on Windows 7, 64 bits, with latest Nightly, following the steps to reproduce from comment #2.

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:23.0) Gecko/20130509 Firefox/23.0, Build ID: 20130509031047.

Comment 40

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

Comment on attachment 746118 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 760036
User impact if declined: failure to load the search service in certain specific scenarios (very dependent on precise timing, which is why it took this long to discover). When it does break, the browser is quite broken.
Testing completed (on m-c, etc.): tested manually, on m-c since May 8
Risk to taking this patch (and alternatives if risky): very low risk
String or IDL/UUID changes made by this patch: none

Comment 41

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/7b685ff14133
https://hg.mozilla.org/releases/mozilla-aurora/rev/581ea0e6531e

Comment 42

[Maria Grazia Alastra [:mga]]

Verified as fixed on Windows 7, 64 bits, with Aurora 22.0, User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130512 Firefox/22.0, Build ID: 20130512004015

Could someone please verify also on Mac?

Comment 44

[Maria Grazia Alastra [:mga]]

This bug is still reproducible on Windows XP (see bug 873947).

Comment 45

[Maria Grazia Alastra [:mga]]

Ok, sorry, the reporter first needs to test it on the beta.

Comment 46

[Ioana (away)]

Tested on Firefox 21 to make sure I can reproduce the issue locally and on 22b2 to verify the fix.

The problem here is that the bug is only fixed for users that will use new profiles on the build with the fix. Here are more details of my steps:

1. Reproduced the bug on Firefox 21.
2. Closed Firefox 21.
3. Started Firefox 22 with the same profile (like the vast majority of our users will. Made sure it was 22 this time).
4. Reproduced the bug on Firefox 22.
5. Changed the settings to remembering history, then back to not remembering it.
6. Reproduced the bug on Firefox 22 again.
7. Closed Firefox 22 and launched it again with a new profile.
8. Tried to reproduce the bug again, but couldn't.

Comment 47

[Ioana (away)]

I tested the above on Ubuntu 13.04 32bit. I can't reproduce the issue at all on Windows 7 64bit (Firefox 21 and 22).

Comment 48

[Ioana (away)]

I tested the same as in comment 46, but with Firefox 23.0b7 instead of 22 (I used a another non-clean profile). The results are the same. I don't think we can mark this bug as verified, or even fixed, since it will keep reproducing for most users that reproduced it with older versions.


FYI: I tried with multiple dirty profiles, but the bug only reproduced with one of them. The only thing that fixed the issue for me, both when done from Firefox 21 and when done from Firefox 23, was resetting my profile.

Comment 49

[u279076]

Michel, please confirm this is now fixed for you, thanks.

Comment 50

[Michel]

Hello Anthony ,
Yes thank you;
Merci,
Rgards from Paris,
Michel.

Comment 51

[u279076]

(In reply to Michel from comment #50)
> Hello Anthony ,
> Yes thank you;
> Merci,
> Rgards from Paris,
> Michel.

I take it that means this is no longer an issue for you?