615785 - about:home is busted in the first window of a new profile (depending on how Firefox is launched)

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Jesse Ruderman]

Steps to reproduce on Linux/trunk:
1. mkdir t1 && firefox -profile t1 http://mozilla.org/
2. Open a new tab.
3. Click the Home button.

Result: Broken about:home
Expected: Working about:home

JavaScript error: chrome://browser/content/aboutHome.js, line 103: gSearchEngine is null

I guess loadDefaultSearchEngine doesn't get called.

Comment 1

[Marco Bonardo [:mak]]

this is known, if you launch the browser passing a url it skips the defaultArgs setting, that includes the setup of the engine. if you don't specify the link, it should work.

Comment 2

[Jesse Ruderman]

Will this bug happen for people who click links in other applications or on the desktop? Or will it only happen for CLI geeks?

Comment 3

[Marco Bonardo [:mak]]

Probably it can also happen by clicking links, but it has also to be the first call in a profile that has never being called without a direct link.
To clarify, this code has to be called only once for each new build, next starts won't call it, the call is made in the defaultArgs getter that is not touched if you pass in a link. So you see the bug in comment 0 because you are creating a new profile (that has never touched defaultArgs) and immediately asking a direct page (that won't touch it).
See http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#574

We could probably change this code to run the new builds check even if defaultArgs is not called, even if it looks a bit risky, I'm unsure how much this startup code is covered by tests.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #2)
> Will this bug happen for people who click links in other applications or on the
> desktop? Or will it only happen for CLI geeks?

FWIW, this happened for a non-technical friend of mine this weekend (which led to me digging a bit & filing a dupe - oops).  I'm not sure how he managed to trigger this bug.  But he was using a long-existing profile, which I'd recently upgraded from 3.6-->4 using Help | Check for Updates and then "Apply Update" to restart in 4. So it wasn't a case of the first Firefox-4-invocation being triggered by a link-click or by CLI.

Comment 8

[Marco Bonardo [:mak]]

we should jut make about:home chrome privileged, move snippets to a type="content" iframe, get a security review. It should be easily feasible without a deadline pressure. At that point we could just move the code from defaultArgs to the page itself.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: reduced prefs.js file from busted profile

Just to follow up a little on Comment 7 -- I reduced the following 2 lines of prefs.js from my friend's profile, which apparently caused it to have a permanently busted about:home
> user_pref("browser.startup.homepage_override.buildID", "20110318052756");
> user_pref("browser.startup.homepage_override.mstone", "rv:2.0");
A fresh profile that starts with those 2 lines in prefs.js will be permanently busted (no matter how Firefox is invoked), AFAICT.

I'm attaching these as a prefs.js file, in case it's helpful.

Comment 10

[Marco Bonardo [:mak]]

(In reply to comment #9)
> > user_pref("browser.startup.homepage_override.buildID", "20110318052756");

this is just telling us that the first run already happened, and it was most llikely the run that busted the page. we won't retry to setup the page till this pref changes (that is the next update). Nothing new here, it's still due to how the browser was invoked after this update/install.

Comment 11

[Jesse Ruderman]

Now the error is:

JavaScript error: chrome://browser/content/abouthome/aboutHome.js, line 145: JSON.parse: unexpected character

Comment 12

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

Marco: this was fixed by bug 749477, right?

Comment 13

[Marco Bonardo [:mak]]

yeah