680798 - "Open Containing Folder" button on about:support error (NS_ERROR_FAILURE) [nsILocalFile.reveal]

Status: REOPENED

(Toolkit :: General, defect, P4)

Description

[Karsten Düsterloh]

Pushing the "Open Containing Folder" button on about:support doesn't work, I only get an error:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.reveal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/aboutSupport.js :: openProfileDirectory :: line 444"  data: no]

Comment 1

[Justin Wood (:Callek)]

Karsten, what SM version did you test this with, and which OS?

Comment 2

[[e-mail]]

I can confirm this bug.  I am using Ubuntu 11.04 64-bit with SeaMonkey 2.3.1.

Comment 3

[therube]

Maybe this is Linux specific?

svip on #seamonkey said:

> Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.1) Gecko/20110830 Firefox/6.0.1 SeaMonkey/2.3.1

> Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsILocalFile.reveal]" nsresult: "0x80004005 (NS_ERROR_FAILURE)"
> location: "JS frame :: chrome://global/content/aboutSupport.js :: openProfileDirectory
> :: line 441" data: no]

Comment 4

[Edmund Wong (:ewong)]

(In reply to therube from comment #3)
> Maybe this is Linux specific?

Yes. I believe it is.  I can confirm on my Slackware Linux.
Mozilla/5.0 (X11; Linux i686; rv:9.0a1) Gecko/20110901 Firefox/9.0a1 SeaMonkey/2.6a1

same error.

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Callek said he got a report of this is happening on Firefox trunk too.

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Works for me on Ubuntu 10.04 with a nightly Firefox build from 8-17.

Also works for me on the most recent 9-1 Nightly build...

So, something with the new Ubuntu interface post 10.04, then?

Comment 7

[Edmund Wong (:ewong)]

Mozilla/5.0 (X11; Linux i686; rv:9.0a1) Gecko/20110902 Firefox/9.0a1

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.reveal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/aboutSupport.js :: openProfileDirectory :: line 443"  data: no]

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

I see this on Kubuntu (KDE; VirtualBox) with all SM versions from 2.1 to 2.9a1 (trunk), plus Nightly (FF trunk).

Since I don't have (and don't want!) a Gnome system, I probably do not fulfill the requirements that nsLocalFile::Reveal() (nsLocalFileUnix.cpp#1800) has to work as expected:

#ifdef MOZ_WIDGET_GTK2
    nsCOMPtr<nsIGIOService> giovfs = do_GetService(NS_GIOSERVICE_CONTRACTID);
    nsCOMPtr<nsIGnomeVFSService> gnomevfs = do_GetService(NS_GNOMEVFSSERVICE_CONTRACTID);
    if (!giovfs && !gnomevfs)
        return NS_ERROR_FAILURE;

Synaptic says I have installed:
* libgnomevfs2-0, libgnomevfs2-common, libgnomevfs2-dev (all 1:2.24.4-1ubuntu1)
* gvfs, gvfs-bin (all 1.10.0-0ubuntu1)

I guess openProfileDirectory() should take care of the failure and display an alert with the path instead.

Moving to Toolkit due to the breakage trigger being in aboutSupport.js. Feel free to move to Core in case nsLocalFileUnix.cpp needs to be fixed instead. And please give this some priority; an important about:support feature is broken on non-Gnome Linux.

Comment 9

[Tony Mechelynck [:tonymec]]

Attachment: output of "rpm -qa | grep ^gnome" on my system

Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120101 Firefox/12.0a1 SeaMonkey/2.9a1 ID:20120101003006
openSUSE Linux 12.1

I have Gnome installed, as shown in the attachment, and yet I see the same error as Karsten in comment #0, and nothing else happens when I click the button in question.

On this build, the error (as "copied" from the Error Console) is:

Error: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.reveal]
Source file: chrome://global/content/aboutSupport.js
Line: 465

Comment 10

[Philip Chee]

Is this a regression? If so regression range wanted. Or perhaps it never worked?

Comment 11

[Tony Mechelynck [:tonymec]]

(In reply to Philip Chee from comment #10)
> Is this a regression? If so regression range wanted. Or perhaps it never
> worked?

I don't know, I don't remember trying it before.
Karsten? Edmund?

Comment 12

[Karsten Düsterloh]

If I understand bug 367596 right, about:support was first seen in Firefox 3.6; this is already broken for me [Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6]:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.reveal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: about:support :: openProfileDirectory :: line 351"  data: no]


The bug is still present these days, e.g. in yesterday's SeaMonkey trunk
[Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120104 Firefox/12.0a1 SeaMonkey/2.9a1]:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.reveal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/aboutSupport.js :: openProfileDirectory :: line 465"  data: no]

Comment 13

[Takanori MATSUURA]

Hmm.

I cannot reproduce with self build on Fedora 16.

By comparing "Configuration arguments" at about:buildconfig", "--enable-gio --disable-gnomevfs" may be affected.

Comment 14

[Jesse Ruderman]

It's broken for me too, using Ubuntu with Unity.

Also, if I use "Open Containing Folder" in the Downloads window, I get an app picker (!?).

Running "nautilus [folder]" from the command line works fine on this system, btw.

Comment 15

[Jens Hatlak (:InvisibleSmiley)]

(In reply to Jesse Ruderman from comment #14)
> Also, if I use "Open Containing Folder" in the Downloads window, I get an
> app picker (!?).

Yeah, because there is no default handler defined for the file: protocol. IOW, if you save your decision, it will be kept. Anyway, that's not this bug (unless someone tries to fix it like in the Downloads window and wonders what's going on of course).

Comment 16

[intendentedelleacque]

I can reproduce this bug on my Debian just removing "libmozgnome.so" from "Components" directory.

Maybe it could be fixed with this change in chrome://global/content/aboutSupport.js ?

-----------------------------------------------------------

function openProfileDirectory() {
  // Get the profile directory.
  let currProfD = Services.dirsvc.get("ProfD", Ci.nsIFile);
  let profileDir = currProfD.path;

  // Show the profile directory.
  let nsLocalFile = Components.Constructor("@mozilla.org/file/local;1",
                                           "nsILocalFile", "initWithPath");

  try {
	  new nsLocalFile(profileDir).reveal();
  }
  catch(e) {
         // Fallback if reveal() will fail
        var file = new nsLocalFile(profileDir);
	 var uri = Components.classes["@mozilla.org/network/io-service;1"].
		getService(Components.interfaces.nsIIOService).newFileURI(file);
	var protocolSvc = Components.classes["@mozilla.org/uriloader/external-protocol-service;1"].
		getService(Components.interfaces.nsIExternalProtocolService);
	protocolSvc.loadUrl(uri);
  }
}

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

Looks like this will be fixed by bug 713802 which will most likely be merged soon \o/.

Comment 18

[Tim Taubert [:ttaubert] (inactive)]

WFM. I'll mark this as fixed by bug 713802.

Comment 19

[Jens Hatlak (:InvisibleSmiley)]

I'm reopening this since I still see it with recent trunk builds of both FF and SM on Kubuntu 12.04. I don't see how bug 713802 could have helped this one. As long as about:support code relies on functionality not provided by hard requirements such as GTK, this bug will continue to exist. As I already suggested in comment 8, it's probably best to just display an alert with the path (and maybe some advice) if the call to reveal() throws.

Comment 20

[Jesse Ruderman]

I'm guessing bug 713802 fixed this for Unity, but not for KDE?