Last Comment Bug 409192 - Applications prefpane is broken if shell service isn't available at runtime (Applications preferences dialogue is empty, no way to add applications)
: Applications prefpane is broken if shell service isn't available at runtime (...
Status: RESOLVED FIXED
: fixed1.9.0.2
Product: Firefox
Classification: Client Software
Component: Preferences (show other bugs)
: 3.0 Branch
: x86 Linux
: -- normal with 5 votes (vote)
: Firefox 3.1a1
Assigned To: Mike Hommey [:glandium]
:
Mentors:
: 428891 439347 (view as bug list)
Depends on: 444922
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-20 05:15 PST by Tony Green
Modified: 2010-03-01 01:56 PST (History)
21 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
apps-prefs.patch (572 bytes, patch)
2008-06-04 03:59 PDT, Alexey Gladkov
gavin.sharp: review-
Details | Diff | Splinter Review
apps-prefs-v1.patch (1.34 KB, patch)
2008-06-06 05:44 PDT, Alexey Gladkov
no flags Details | Diff | Splinter Review
proposed patch (893 bytes, patch)
2008-06-15 12:50 PDT, Mike Hommey [:glandium]
gavin.sharp: review+
mbeltzner: approval1.9.0.2+
Details | Diff | Splinter Review

Description Tony Green 2007-12-20 05:15:43 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2

Click Edit->Preferences->Applications and the applications dialogue opens up, but it is completely empty. There is no apparent way to populate it.

I have confirmed that this is the case whether or not I'm using an existing profile and have also run Firefox in debug mode to see if there were any useful messages when I open the dialogue, but there weren't.

mimetypes.rdf IS populated and (at least from an empty profile) I can add new handlers by choosing them when I click, for instance, a mailto: link.

This was also the case with Beta 1, but I've only just realised it was an issue.

Reproducible: Always

Steps to Reproduce:
1. Click Edit
2. Click Preferences
3. Click Applications
Actual Results:  
Empty dialogue box with no way to add anything

Expected Results:  
I would expect to see the registered applications, with the option of changing them or adding new ones.
Comment 1 Stephen Donner [:stephend] 2007-12-28 16:25:59 PST
Are you:
* running any extensions, and if so, which ones?
* seeing any exceptions/errors thrown in the Error Console?
Comment 2 Hideo Oshima 2008-01-15 06:26:26 PST
I can reproduce this problem with recent trunk build.
I use no extensions.

Following message is in Error Console
Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/preferences/applications.js :: <TOP_LEVEL> :: line 444"  data: no]

Additional Information:
No icon is displayed in Download Manager.
Comment 3 Florian Quèze [:florian] [:flo] (PTO until August 29th) 2008-01-15 18:59:03 PST
This looks like a dup of bug 410900.
Comment 4 Hideo Oshima 2008-01-18 07:27:04 PST
(In reply to comment #3)
> This looks like a dup of bug 410900.
 
I tested again.
Official trunk build doesn't have this problem
but my private build does.

So my problem may be another one.
Comment 5 Joel Cunningham 2008-03-24 15:13:57 PDT
I'm experiencing an empty applications dialog box on beta 4 with the official linux binary.

Screenshot: http://img291.imageshack.us/img291/9184/ff3beta4blankapplicatioic6.png

This shows up in the error console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/preferences/applications.js :: <TOP_LEVEL> :: line 478"  data: no]
Comment 6 Tony Green 2008-04-03 04:06:53 PDT
Just to confirm, this bug is still affecting me after installing Beta 5. The error console shows the same message reported by Joel.
I see the same problem both with my existing profile and also when I delete it and start afresh.

One thought about this: I'm running an Ubuntu 64-bit system, but the version of Firefox is 32-bit. Could there be something significant in this? If I could find a 64-bit version of any of the betas showing this problem, I could test and either confirm or eliminate this.
Comment 7 Youri Volkov 2008-04-03 07:04:07 PDT
64 bit has no significane. I am running 32 bit system and have same problem. 
Comment 8 Joel Cunningham 2008-04-03 07:29:52 PDT
I upgraded to beta5 yesterday and this bug is still persistent, both with my current profile and a new one.  Same error shows up in the error console
Comment 9 Patrick McCarty 2008-04-21 19:04:31 PDT
I am experiencing the same issue with Fx3b5 and the latest nightly build.  The bug's description and the error message in the error console are identical to those listed above.  I am running a 32-bit system.

I have one other observation that may be relevant - After creating a new profile and starting Firefox, I have two additional "messages" that appear in the error console (where <path to firefox directory> is unique to my machine):

Failed to load XPCOM component: /<path to firefox directory>/firefox/components/libmozgnome.so

Failed to load XPCOM component: /<path to firefox directory>/firefox/components/libnkgnomevfs.so

On every subsequent Firefox session, these messages do not appear.  Could this be a related issue?
Comment 10 Tony Green 2008-05-17 08:36:41 PDT
I just installed RC1 and this bug is still present, both with an existing profile and when restarting with the profile deleted.

I can't help thinking that it's the sort of bug that the knockers (especially those at Redmond) will get great fun shouting about if Firefox 3 gets released with this still a problem.
Comment 11 Patrick McCarty 2008-05-17 11:09:22 PDT
FWIW, I found a workaround for this bug:

1) Install GConf and its dependencies
2) Start Firefox with a fresh profile

Now, on my system, the Applications pref pane is populated, and the "default browser check" mechanism also works (In the Advanced -> General tab).

I asked about this on IRC.  Apparently GConf is a runtime dependency, and the fallback functionality is a little buggy.
Comment 12 Tony Green 2008-05-17 11:15:48 PDT
(In reply to comment #11)
> FWIW, I found a workaround for this bug:
> 
> 1) Install GConf and its dependencies
> 2) Start Firefox with a fresh profile

Unfortunately this doesn't appear to be the problem for me, as GConf (or at least, GConf2) is already installed. As is gconf2-common, libgconf2-4 and python-gconf.

...unless there's another library that should be installed which isn't a dependency on Kubuntu...
Comment 13 Matthieu Bedouet 2008-05-17 15:51:59 PDT
the thrown exception is not handled at line 478 in applications.js.
I'm not sure what impacts on performance this fix could cause when 
getService(Ci.nsIShellService) actually works.
is it normal that an exception occurs in the first place?


delete this at line 475

_shellSvc:
//@line 541 "/builds/tinderbox/Fx-Mozilla1.9-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/components/preferences/applications.js"
    Cc["@mozilla.org/browser/shell-service;1"].
    getService(Ci.nsIShellService),*/
//@line 546 "/builds/tinderbox/Fx-Mozilla1.9-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/components/preferences/applications.js"


and modify this at line 607

//@line 669 "/builds/tinderbox/Fx-Mozilla1.9-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/components/preferences/applications.js"
    try {
      defaultFeedReader = Cc["@mozilla.org/browser/shell-service;1"].
                            getService(Ci.nsIShellService).defaultFeedReader;
    }
    catch(ex) {
      // no default reader
    }
//@line 676 "/builds/tinderbox/Fx-Mozilla1.9-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/components/preferences/applications.js"



and this at line 634

//@line 695 "/builds/tinderbox/Fx-Mozilla1.9-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/components/preferences/applications.js"
    try {
      if (Cc["@mozilla.org/browser/shell-service;1"].
                getService(Ci.nsIShellService).defaultFeedReader)
        return true;
    }
    catch(ex) {
      // no default reader
    }
//@line 703 "/builds/tinderbox/Fx-Mozilla1.9-Release/Linux_2.6.18-53.1.13.el5_Depend/mozilla/browser/components/preferences/applications.js"


after that the applications are shown in the preferences.

Comment 14 Arek Olek 2008-05-19 04:29:13 PDT
On Ubuntu installing firefox-gnome-support package fixes this.
Comment 15 Tony Green 2008-05-19 04:37:33 PDT
(In reply to comment #14)
> On Ubuntu installing firefox-gnome-support package fixes this.
> 

I've tried this, but it didn't work.

But I realised why. My system is a 64-bit OS, but of course the Firefox Betas and release candidate are only available in 32-bit, so naturally won't be able to use any 64-bit libraries that are installed.

Looks like I'll have to wait for the final release, when there will hopefully be a 64-bit build.
Comment 16 Markus N. 2008-05-30 11:45:11 PDT
I installed the latests repo version of FF3 RC1 (3.0~rc1+nobinonly-0ubuntu0.8.04.1) on my xubuntu hardy box this afternoon and I have the same problem. This started with FF3b5. Creating a new profile doesn't affect the applications dialog. I always have to find the application manually for a file to open.
Comment 17 Alexey Gladkov 2008-06-04 03:59:51 PDT
Created attachment 323696 [details] [diff] [review]
apps-prefs.patch

I think, Bug Severity should be major or blocker. This dialog is completely broken.

This simple patch should fix this problem. Please, test it.
Comment 18 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-06-05 16:34:40 PDT
Comment on attachment 323696 [details] [diff] [review]
apps-prefs.patch

This breaks the existing callers - you need to change them to use _shellSvc().
Comment 19 Alexey Gladkov 2008-06-06 05:44:27 PDT
Created attachment 324035 [details] [diff] [review]
apps-prefs-v1.patch

Calls of _shellSvc() are changed.
Comment 20 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-06-09 07:04:28 PDT
Comment on attachment 324035 [details] [diff] [review]
apps-prefs-v1.patch

Could you also remove the try/catch blocks, and use a local variable and null check instead? This looks fine otherwise.
Comment 21 Alexey Gladkov 2008-06-09 07:25:21 PDT
We shouldn't remove the try/catch blocks. If we do so, will have same exception.

I still do not understand why this exception happens. _converterSvc: initialize properly.
Comment 22 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-06-09 13:56:04 PDT
It's failing because of bug 383348 or bug 297841, presumably.
Comment 23 Alexey Gladkov 2008-06-09 16:13:57 PDT
Yes. It is definitely my case. I use gtk and don't have gconf.
Comment 24 Tony Green 2008-06-12 10:44:58 PDT
I have noticed something strange(In reply to comment #15)
> (In reply to comment #14)
> > On Ubuntu installing firefox-gnome-support package fixes this.
> > 
> 
> I've tried this, but it didn't work.
> 
> But I realised why. My system is a 64-bit OS, but of course the Firefox Betas
> and release candidate are only available in 32-bit, so naturally won't be able
> to use any 64-bit libraries that are installed.
> 
> Looks like I'll have to wait for the final release, when there will hopefully
> be a 64-bit build.
> 

Since Ubuntu has released an update with the release candidate, I've now been able to run a 64-bit version of Firefox 3. The dialogue IS now populated, but Firefox is ignoring the selections I make there. I've even tried setting the actions to "always ask" in the hope that the dialogue at the point of clicking a link might actually set the application, but Firefox is still using the applications that were originally selected, with no apparent way to set a different one.
Comment 25 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-06-15 12:31:24 PDT
*** Bug 439347 has been marked as a duplicate of this bug. ***
Comment 26 Mike Hommey [:glandium] 2008-06-15 12:50:44 PDT
Created attachment 325195 [details] [diff] [review]
proposed patch

Are comments enough like this ?
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-06-15 13:13:55 PDT
Comment on attachment 325195 [details] [diff] [review]
proposed patch

If we're going to end up doing runtime error handling either way, we might as well just remove the HAVE_SHELL_SERVICE defines... not this bug, though.
Comment 28 Claudio Fontana 2008-06-17 12:36:33 PDT
I am also experiencing the exact same bug,
with firefox-3.0 final, on slackware 12, using fluxbox only.

Comment 29 Claudio Fontana 2008-06-17 12:41:10 PDT
It seems from reading the comments above and the related bugs that
a full desktop environment like gnome or kde might be needed to
be able to run firefox in the future.

If so, this is a big change of dependencies from the past,
and might prevent users like me to continue choosing it as a browser.

Comment 30 Joel Cunningham 2008-06-17 13:13:58 PDT
"It seems from reading the comments above and the related bugs that
a full desktop environment like gnome or kde might be needed to
be able to run firefox in the future."

I use KDE and have had this since beta 3...maybe it only works correctly on Gnome?
Comment 31 Mike Hommey [:glandium] 2008-06-18 01:01:29 PDT
It only work if you have the gnome libraries installed. you don't need to run gnome.
Comment 32 Jonas Flodén 2008-06-18 01:37:28 PDT
*** Bug 428891 has been marked as a duplicate of this bug. ***
Comment 33 Alexander Sack 2008-06-24 03:19:31 PDT
(In reply to comment #31)
> It only work if you have the gnome libraries installed. you don't need to run
> gnome.
> 

Well, but using gnome APIs will make you use the gnome mime-type database, which might or might not the thing you want here.
Comment 34 Ken Zalewski 2008-06-25 12:25:56 PDT
I am having the same problem with Firefox 3 on Slackware 12.1.  Thunderbird no longer launches when I click on a mailto: URL, even though the network.protocol-handler.app.mailto pref is set to "/usr/bin/thunderbird".  And the Applications panel is empty, with no means to modify it.

I then built and installed the following GNOME packages:
orbit2, gconf, gnome-mime-data, gnome-vfs, intltool, libbonobo, and libgnome

Next, I deleted the compreg.dat file in my Firefox profile directory, and I commented out the line in firefox.js that sets the mailto preferences mentioned above.

After restarting Firefox 3, the Applications panel is now populated, and I can set the mailto URL to open Thunderbird, Yahoo, or whatever else I choose.

I find it disturbing that Firefox 3 requires all of these GNOME libraries.  Slackware is a KDE distro, and there must be a more desktop-independent method for accessing MIME data.  Seven libraries to simply perform a hash table storage and retrieval is unacceptable.
Comment 35 // 2008-06-26 14:13:30 PDT
Hello,

I registered here for the sole purpose of expressing my concern regarding significance of this bug.

Current situation prevents users of non-Gnome based desktops from taking advantage of a core functionality (we are talking dozens of thousands people here). That is not only against the spirit of Free Software Movement, basically forcing many users to install at least some gnome-dependencies (from what I gather) but also adds unnecessary complexity and slightly sharpens the hardware requirements, especially regarding memory and disk use. I am personally considering to abandon XFCE if I was forced to include gconf, libgnome and gnome-vfs just to run a webbrowser.

A failover solution for people running minimal environments (old desktops, server terminals, some embedded hardware perhaps?) is in my opinion, and judging by comments on bugtrackers of various distributions - very much needed.

And now that the release version is still affected I can't stress more how important this bug is.

Regards,
J.
Comment 36 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-06-26 17:10:40 PDT
There's no need to continue to post comments about the severity of this bug. It already has a reviewed patch and we're going to fix it.

What *would* be useful would be for someone to take ownership of the bug and get the patch pushed to mozilla-central in advance of the approval requests being triaged. I should be able to push it tomorrow if no one else gets to it before then.
Comment 37 Ken Zalewski 2008-07-08 18:18:26 PDT
I re-compiled Firefox 3.0 on Slackware 12.1 with the patch listed above (attachment 325195 [details] [diff] [review]), and without any GNOME libs being installed (except for GTK+2, Pango, and Cairo).

The Applications Panel works fine now, and Thunderbird opens properly when clicking on a mailto: URL.

In my opinion, the patch fixes the problem and should be made official.
Comment 38 Reed Loden [:reed] (use needinfo?) 2008-07-12 02:01:12 PDT
Pushed as 15836:1c8fc62b5eff. Will commit to 1.9.0 branch shortly.
Comment 39 Reed Loden [:reed] (use needinfo?) 2008-07-12 02:08:17 PDT
CVS HEAD (1.9.0 branch):

Checking in browser/components/preferences/applications.js;
/cvsroot/mozilla/browser/components/preferences/applications.js,v  <--  applications.js
new revision: 1.45; previous revision: 1.44
done
Comment 40 Matt VanEseltine 2008-07-12 09:34:17 PDT
Although this patch helps, it does not appear to be a complete fix.  While the panel is indeed repopulated, all of the "application details" menus from the Action dropdown are empty in my install (patched recompiled Gentoo ebuild).
Comment 41 Mike Hommey [:glandium] 2008-07-12 09:43:24 PDT
(In reply to comment #40)
> Although this patch helps, it does not appear to be a complete fix.  While the
> panel is indeed repopulated, all of the "application details" menus from the
> Action dropdown are empty in my install (patched recompiled Gentoo ebuild).

That probably means you have not many plugins installed, and your mailcap is mostly empty.
Comment 42 Matt VanEseltine 2008-07-12 10:03:38 PDT
(In reply to comment #41)
> That probably means you have not many plugins installed, and your mailcap is
> mostly empty.

Both of these things are more or less the case - not many plugins, and my mailcap is not dealing specifically with any of the content types in Firefox's application list.

However, for a direct point of comparison, the "Web Feed" content type has an identical dropdown list on both this patched Gentoo install and on my other machine with XP (both recent fresh 3.0 installs).  There are three built-in Firefox web applications on that list: Bloglines, My Yahoo, Google.  In XP, "Application Details" lists all three of those with URLs and the option to remove them from the list.  In Gentoo, "Application Details" shows nothing.

But if it's just my problem, then I'm not particularly concerned.
Comment 43 Mike Hommey [:glandium] 2008-07-12 10:09:35 PDT
I agree there seems to be something fishy. Can you please file another bug for this ? (and give the id)
Comment 44 Matt VanEseltine 2008-07-12 10:35:30 PDT
(In reply to comment #43)
> I agree there seems to be something fishy. Can you please file another bug for
> this ? (and give the id)

Okay, I filed bug 444922 ...
Comment 45 Takeshi Kovacs 2008-07-18 07:07:58 PDT
> There's no need to continue to post comments about the severity of this bug. It
> already has a reviewed patch and we're going to fix it.

It took *years* to fix this (is it really fixed? can we call it fixed with half of gnome installed?), there are bug reports almost from the *last century*! So I doubt people really understood the severity of this annoyance.

Thanks for your hard work.
Comment 46 Mike Hommey [:glandium] 2008-07-18 08:05:12 PDT
You don't need gnome for the applications prefpane to work properly with the patches from this bug and bug 444922 applied.
Comment 47 Reed Loden [:reed] (use needinfo?) 2008-07-18 08:17:24 PDT
(In reply to comment #45)
> It took *years* to fix this (is it really fixed? can we call it fixed with half
> of gnome installed?), there are bug reports almost from the *last century*! So
> I doubt people really understood the severity of this annoyance.

What are you talking about? This bug was filed in Dec. 2007, and the Applications prefpane was only created last year sometime.
Comment 48 Joel Cunningham 2008-07-18 08:21:19 PDT
(In reply to comment #47)
> (In reply to comment #45)
> > It took *years* to fix this (is it really fixed? can we call it fixed with half
> > of gnome installed?), there are bug reports almost from the *last century*! So
> > I doubt people really understood the severity of this annoyance.
> 
> What are you talking about? This bug was filed in Dec. 2007, and the
> Applications prefpane was only created last year sometime.
> 

I think he was just being sarcastic and bitter about how long this took to fix and the fact that 3.0 was released before this was fixed.
Comment 49 Al Billings [:abillings] 2008-09-05 16:13:14 PDT
Do we have a clean repro scenario? Reading through the comments, it isn't clear to me how to 100% validate this fix for 1.9.0.2.
Comment 50 RRP-WebGuy 2010-02-28 11:40:07 PST
If this is 'fixed' or 'resolved', then why is the Applications panel not functioning? I'm running FireFox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6) on an PC with XP MCE.

The console error is: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMXULDocument.loadOverlay]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://downbar/content/privacyPrefsOverlay.js :: showPane :: line 62"  data: no]

The Apps panel will not open. All the other Options tabs work fine, but whenever Applications is selected, the tab turns grey as though it is selected, but the content from the previously selected panel remains.  What's going on here???
Comment 51 Mike Hommey [:glandium] 2010-02-28 23:12:42 PST
That would be a regression. I guess this should go in a new bug report.
Comment 52 Florian Quèze [:florian] [:flo] (PTO until August 29th) 2010-03-01 00:00:37 PST
The problem in comment 50 looks a lot like bug 330458.

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