The problem is actually a different one: firefox is NOT SHOWING THE DEFAULT HOME
PAGE ON STARTUP (unless the user has overridden the system default home page
with a customized one; then it seems to work okay).

The reason it is blanking out any attempt to set http://start.fedoraproject.org
as the user-defined homepage is that that already is the system-default
homepage, and there is no point having the user's prefs.js file replicating what
is already in the system default file (this makes it easier to change the system
default down the road, without all users having to change their individual
prefs.js files).

The problem is that, although http://start.fedoraproject.org is set as the start
page, firefox is not opening that page on startup. (If you click the Home icon,
though, it does open it).

This is a serious problem for us as we customize our firefox installation to
show our home page by default. Now that we are upgrading to Fedora 8, firefox no
longer shows our home page (or any home page) when it starts up -- users have to
explicitly click on the HOME icon to get it.

I'm going to start looking at the code to see if I can find a cause and a patch
to fix it...

Okay, the problem is that the function getComplexValue is somehow crashing.

If you edit the file /usr/lib*/firefox*/components/nsBrowserContentHandler.js

and immediately after the lines

    get startPage() {
    var prefb = Components.classes["@mozilla.org/preferences-service;1"]
                          .getService(nsIPrefBranch);

insert the line

    return "file:///"

then start firefox, it opens with "file:///" as the start page -- as it should,
because the above statement short-circuits the processing logic.

If, however, you move the return "file:///" line down to just after the
next statement, 

     var uri = prefb.getComplexValue("browser.startup.homepage",
                                    nsIPrefLocalizedString).data;

and then start firefox (from a user profile that does NOT have a home page
preference assigned), it opens with a blank page instead.

That means that return command is not being executed, which means that the
invocation of the prefb.getComplexValue command is throwing some sort of
exception which is aborting the entire startPage calculation routine.

Indeed, the JavaScript error console shows the following information:

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIPrefBranch.getComplexValue]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
file:///usr/lib/firefox-2.0.0.10/components/nsBrowserContentHandler.js ::
anonymous :: line 517"  data: no]
Source File: file:///usr/lib/firefox-2.0.0.10/components/nsBrowserContentHandler.js
Line: 499

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://browser/content/browser.js :: anonymous :: line 3890"  data: no]

[ Note -- line numbers above may be slightly off as I've been playing around
with the file a bit to debug this.]

I'll keep looking to see why getComplexValue is crashing ...


 

Created attachment 286351 [details]
Patch to work around problem of system-default home page not being displayed

The preceding patch (which can be applied directly to
/usr/lib*/firefox*/components/nsBrowserContentHandler.js, no need to recompile)
will work around the problem by trying the same "formatURLPref" method to find
the startup homepage when getComplexValue fails.

With this patch, the system-default homepage now shows correctly.

I suspect the real cause is that browser.startup.homepage is now supposed to be
specified in some more elaborate ("Complex...") method in the system default
files, and that somebody forgot to change the default when changing the code
that looks it up. However, this patch is probably a good idea anyway, to allow a
fallback to the old method when the new method (whatever it is) fails.

Thanks for the work here.  Does formatURLPref always work?  Should we simply use
that in all cases?

After looking further, yeah, formatURLPref is what we want.  I'll commit a
modified patch that works just as well, but thanks for your investigation here!

This will be fixed in firefox-2.0.0.10-3.fc8 and firefox-2.0.0.10-5.fc9

The only thing I'd be leery of in using formatURLPref only is whether or not
getComplexValue might be capable of getting something other than a single URL,
for example, a group of URLs to be displayed in different tabs, that
formatURLPref would choke on.

There's probably one more thing that needs to be fixed to completely resolve the
original poster's issue: the home page prefence display, where it currently
blanks out anything equal to the system default, should instead blank it out
ONLY in the user's prefs.js file but leave it filled in on the screen (and, when
the user's prefs.js file has no browser.startup.homepage entry, it should show
the system default on the screen instead of a blank box).

There are two problems with the way it is now:
   (1) The user cannot set a home page that is a SUBSET of the system default
       page by typing. E.g., if the user wanted to set
       http://start.fedora.org/foo as the home page, they would have to
       either paste it in to the window or get it there some other way. If
       they try to type it in, the window goes blank as soon as they type
       the penultimate / character.
   (2) The user doesn't get any information about what the default home page
       is.

(In reply to comment #8)
> The only thing I'd be leery of in using formatURLPref only is whether or not
> getComplexValue might be capable of getting something other than a single URL,
> for example, a group of URLs to be displayed in different tabs, that
> formatURLPref would choke on.

If the user's homepage is multiple pages, then they will ought to have the
"browser.startup.homepage.count" pref set and "browser.startup.homepage.<N>"
(where <N> is an incrementing index from 1 to count-1) which is what the
following block of code checks on.  Also, all getComplexValue really signifies
that it is a value of not a very basic type: int, bool, or char* (ASCII).  Since
URIs may fall out of the ASCII range, it is an nsIPrefLocalizedString (which is
essentially UTF-8).

firefox-2.0.0.10-3.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

I'm using the latest firefox package and issue still persists.

[root@be-bons-18 ~]# rpm -qa firefox
firefox-2.0.0.10-3.fc8


Thanks for the help,
Paulo

Ah, right.  I only fixed the default case.  Sorry.  Will look into what the pref
field is doing...  In the meantime, a workaround should be to do it in about:config

In about:config i have:
browser.startup.homepage - http://start.fedoraproject.org/
startup.homepage_override_url - http://start.fedoraproject.org/
startup.homepage_welcome_url - http://start.fedoraproject.org/

Even so all of this are set, i still get the default firefox/google page when
clicking on the homepage icon, unless opening a new browser.

Is there any other option that controls the homepage icon in firefox, that i can
try to setup in about:config ?


Thanks,
Paulo

At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.

At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.

Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

[This is a mass-closing request, if you think that this bug shouldn't be closed,
please, reopen with additional information.]

This is still a problem.  Reopening

*** Bug 446592 has been marked as a duplicate of this bug. ***

Fixed in 3.0.4 in both F9 and F-10.  I also added the patch to 2.0.0.18 in FC8 but not sure if it works there.  Either way, closing this out now as CURRENTRELEASE since this does work in both F9 and F10