Bug 412021 - start.fedoraproject.org unable to be used as predefined home page
start.fedoraproject.org unable to be used as predefined home page
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Christopher Aillon
Fedora Extras Quality Assurance
firefox3INSUFFICIENT_DATAmassClosing
: Patch, Reopened
: 446592 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-05 09:20 EST by Paulo Santos
Modified: 2008-11-15 13:02 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-15 13:02:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to work around problem of system-default home page not being displayed (1.29 KB, patch)
2007-12-12 18:45 EST, Philip Spencer
no flags Details | Diff

  None (edit)
Description Paulo Santos 2007-12-05 09:20:17 EST
Description of problem:
I've upgraded my desktop from F7 to F8 and then tried to set
http://start.fedoraproject.org to the predefined homepage in FF2. It will blank
the field and not accept the desired url.

Version-Release number of selected component (if applicable): Fedora/2.0.0.10-2.fc8

How reproducible:
Always. Tried in two different laptops, one upgraded from F7 to F8 the other
from F6 to F8.

Steps to Reproduce:
1. Choose any URL to use as home page in FF2
2. Then try to setup http://start.fedoraproject.org
  
Actual results:
It will blank the field, and defaults to the default Firefox page

Expected results:
Would be nice to use http://start.fedoraproject.org since thats why it was setup
Comment 1 Philip Spencer 2007-12-12 16:37:35 EST
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...
Comment 2 Philip Spencer 2007-12-12 17:24:29 EST
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 ...


 
Comment 3 Philip Spencer 2007-12-12 18:45:38 EST
Created attachment 286351 [details]
Patch to work around problem of system-default home page not being displayed
Comment 4 Philip Spencer 2007-12-12 18:47:29 EST
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.
Comment 5 Christopher Aillon 2007-12-13 08:25:11 EST
Thanks for the work here.  Does formatURLPref always work?  Should we simply use
that in all cases?
Comment 6 Christopher Aillon 2007-12-13 09:33:55 EST
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!
Comment 7 Christopher Aillon 2007-12-13 09:41:49 EST
This will be fixed in firefox-2.0.0.10-3.fc8 and firefox-2.0.0.10-5.fc9
Comment 8 Philip Spencer 2007-12-13 13:22:21 EST
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.
Comment 9 Christopher Aillon 2007-12-13 17:37:36 EST
(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).
Comment 10 Fedora Update System 2007-12-15 12:48:55 EST
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.
Comment 11 Paulo Santos 2007-12-18 07:50:27 EST
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
Comment 12 Christopher Aillon 2007-12-19 12:02:03 EST
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
Comment 13 Paulo Santos 2008-01-21 11:21:42 EST
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
Comment 14 Matěj Cepl 2008-02-21 17:34:30 EST
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.
Comment 15 Matěj Cepl 2008-02-21 17:35:44 EST
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.
Comment 16 Matěj Cepl 2008-04-09 10:05:00 EDT
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.]
Comment 17 Christopher Aillon 2008-06-27 17:03:12 EDT
This is still a problem.  Reopening
Comment 18 Christopher Aillon 2008-06-27 17:03:44 EDT
*** Bug 446592 has been marked as a duplicate of this bug. ***
Comment 19 Christopher Aillon 2008-11-15 13:02:33 EST
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

Note You need to log in before you can comment on or make changes to this bug.