Bug 486861 - Perferred Application applet crashes after firefox registers as default browser
Summary: Perferred Application applet crashes after firefox registers as default browser
Keywords:
Status: CLOSED DUPLICATE of bug 483225
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Jan Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-22 16:36 UTC by D Levin
Modified: 2009-02-24 15:23 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-02-24 15:23:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description D Levin 2009-02-22 16:36:07 UTC
Description of problem:
On a new installation of FC10 (2.6.27.12-170.2.5.fc10.i686) I allowed firefox 3.0.6 to register itself as the default web browser; thereafter
System -> Preferences -> Personal -> Preferred Applications crashes and sends a bug report: http://crash.gnome.org/report/index/a49315f4-003d-11de-8ac9-0007e9333148?date=2009-02-21-17

Server is inaccessible, so I've duplicated this bug in bugzilla so I can track progress.



Version-Release number of selected component (if applicable):
See http://crash.gnome.org/report/index/a49315f4-003d-11de-8ac9-0007e9333148?date=2009-02-21-17
and others ...


How reproducible: Consistent


Steps to Reproduce:
1. run firefox 3.0.6
2. Edit -> Preferences -> Advanced -> General -> Check Now
3. Set Firefox as default browser
4. on Gnome panel select:
   System -> Preferences -> Personal -> Preferred Applications
5. applet crashes and send report
  
Actual results:
crash

Expected results:
invocation of applet

Additional info:
multiple reports sent to http://crash.gnome.org/report/index

Comment 1 Matthias Clasen 2009-02-23 07:19:17 UTC
I haven't been able to reproduce the crash, but certainly firefox should not register itself with the full path to the binary.

Comment 2 Jan Horak 2009-02-23 08:32:36 UTC
About full path, see #474461.

However upstream prefer full path (to let you have more Firefox installations in one system, as Chris told me):
https://bugzilla.mozilla.org/show_bug.cgi?id=469648

Comment 3 Christopher Aillon 2009-02-23 15:47:16 UTC
Well, that should only be set if you do a check for the default browser which we should be disabling.  Apparently something in 3.1 changed where our fix only works for the default value but still lets you manually change the value and even lets you manually check it.

The reason we sort of need this still is if someone downloads a mozilla.org build and sets that to be the default browser... and then wants to reset it back to be our packaged version....

I suppose we should investigate what relies on nsGNOMEShellService::mAppName and see if we can simply init that to be 'firefox' so the check in nsGNOMEShellService::KeyMatchesAppName will succeed...  I'm unsure if changing that will break other things though....

A better patch which upstream may take would be to have something like "IsDistroBuild()" which we would make sure would always be true for our bits, and then modify IsDefaultBrowser() to check if it's a distro build first and if so, then compare against 'firefox %s' and if not, do what it's doing now....

I wonder if IsDistroBuild() could key off the general.useragent.vendor pref?

Comment 4 D Levin 2009-02-23 16:22:50 UTC
Just to chime in, no mozilla.org build was used in the creation of this bug.  I took everything from the FC10 distro.

Anyone care to insert some instructions into this comment stream, so I can correct my env and let the applet run?  Thanks in advance

Comment 5 Jan Horak 2009-02-24 10:36:55 UTC
The gnome-default-applications-properties changes following gconf variables:

/desktop/gnome/url-handlers/https/command (should be set to 'firefox %s')
/desktop/gnome/url-handlers/about/command (should be set to 'firefox %s')
/desktop/gnome/url-handlers/http/command (should be set to 'firefox %s')
/desktop/gnome/applications/browser/exec (should be set to 'firefox')

You may send us your previous variables values (but I'm not sure how much this could be helpful).

Anyway by testing it I can replicate this crash on F10, FF 3.0.6. I can look into it.

Comment 6 Jan Horak 2009-02-24 15:23:21 UTC
According to changelog and my testing the crash should be already fixed in upcoming package version 2.24.0.1-13

*** This bug has been marked as a duplicate of bug 483225 ***


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