Closed Bug 409192 Opened 17 years ago Closed 16 years ago

Applications prefpane is broken if shell service isn't available at runtime (Applications preferences dialogue is empty, no way to add applications)

Categories

(Firefox :: Settings UI, defect)

3.0 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3.1a1

People

(Reporter: foxfire, Assigned: glandium)

References

Details

(Keywords: fixed1.9.0.2)

Attachments

(1 file, 2 obsolete files)

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.
Are you:
* running any extensions, and if so, which ones?
* seeing any exceptions/errors thrown in the Error Console?
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.
This looks like a dup of bug 410900.
(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.
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]
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.
64 bit has no significane. I am running 32 bit system and have same problem. 
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
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?
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.
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.
(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...
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.

On Ubuntu installing firefox-gnome-support package fixes this.
(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.
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.
Attached patch apps-prefs.patch (obsolete) — Splinter Review
I think, Bug Severity should be major or blocker. This dialog is completely broken.

This simple patch should fix this problem. Please, test it.
Attachment #323696 - Flags: review?(gavin.sharp)
Comment on attachment 323696 [details] [diff] [review]
apps-prefs.patch

This breaks the existing callers - you need to change them to use _shellSvc().
Attachment #323696 - Flags: review?(gavin.sharp) → review-
Attached patch apps-prefs-v1.patch (obsolete) — Splinter Review
Calls of _shellSvc() are changed.
Attachment #323696 - Attachment is obsolete: true
Attachment #324035 - Flags: review?(gavin.sharp)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: FF3B2: Applications preferences dialogue is empty and has no way to add applications → Applications prefpane is broken if shell service isn't available at runtime (Applications preferences dialogue is empty, no way to add applications)
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.
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.
It's failing because of bug 383348 or bug 297841, presumably.
Yes. It is definitely my case. I use gtk and don't have gconf.
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.
Attached patch proposed patchSplinter Review
Are comments enough like this ?
Attachment #324035 - Attachment is obsolete: true
Attachment #325195 - Flags: review?(gavin.sharp)
Attachment #324035 - Flags: review?(gavin.sharp)
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.
Attachment #325195 - Flags: review?(gavin.sharp) → review+
I am also experiencing the exact same bug,
with firefox-3.0 final, on slackware 12, using fluxbox only.

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.

"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?
It only work if you have the gnome libraries installed. you don't need to run gnome.
(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.
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.
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.
Attachment #325195 - Flags: approval1.9.0.1?
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.
Assignee: nobody → mh+mozilla
Keywords: checkin-needed
Attachment #325195 - Flags: approval1.9.0.1? → approval1.9.0.2+
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.
Pushed as 15836:1c8fc62b5eff. Will commit to 1.9.0 branch shortly.
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1a1
Version: unspecified → 3.0 Branch
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
Keywords: fixed1.9.0.2
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).
(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.
(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.
I agree there seems to be something fishy. Can you please file another bug for this ? (and give the id)
(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 ...
Depends on: 444922
> 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.
You don't need gnome for the applications prefpane to work properly with the patches from this bug and bug 444922 applied.
(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.
(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.
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.
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???
That would be a regression. I guess this should go in a new bug report.
The problem in comment 50 looks a lot like bug 330458.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: