Open
Bug 680798
Opened 13 years ago
Updated 2 years ago
"Open Containing Folder" button on about:support error (NS_ERROR_FAILURE) [nsILocalFile.reveal]
Categories
(Toolkit :: General, defect, P4)
Tracking
()
REOPENED
People
(Reporter: mnyromyr, Unassigned)
References
Details
(Whiteboard: [Gecko6-affected])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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 2•13 years ago
|
||
I can confirm this bug. I am using Ubuntu 11.04 64-bit with SeaMonkey 2.3.1.
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•13 years ago
|
||
(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.
OS: All → Linux
Comment 5•13 years ago
|
||
Callek said he got a report of this is happening on Firefox trunk too.
Product: SeaMonkey → Firefox
QA Contact: general → general
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•13 years ago
|
||
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•13 years ago
|
||
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.
Product: Firefox → Toolkit
QA Contact: general → general
Version: unspecified → Trunk
Comment 9•13 years ago
|
||
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
Updated•13 years ago
|
![]() |
||
Comment 10•13 years ago
|
||
Is this a regression? If so regression range wanted. Or perhaps it never worked?
Comment 11•13 years ago
|
||
(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?
Reporter | ||
Comment 12•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
Looks like this will be fixed by bug 713802 which will most likely be merged soon \o/.
Depends on: 713802
Comment 18•12 years ago
|
||
WFM. I'll mark this as fixed by bug 713802.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 19•12 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•