"Open containing folder" is only working if nautilus is present

[Manuel López-Ibáñez]

Binary package hint: firefox

Tools->Downloads-> (Right click)->Open containing folder

Result: Nothing happens (not even an error).
Expected: An error, a dialog asking to choose a file manager or just konqueror showing the folder.

Fix: add the following line to prefs.js
user_pref("network.protocol-handler.app.file", "konqueror");

ProblemType: Bug
Architecture: i386
Date: Fri Aug 17 12:54:22 2007
DistroRelease: Ubuntu 7.04
Package: firefox 2.0.0.5+1-0ubuntu1
PackageArchitecture: i386
SourcePackage: firefox
Uname: Linux localhost 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux

[Johann Petrak (johann-petrak)]

This has been tested with the 1.0RC1.
When right-clicking a download in the download manager, the option "open
containing folder" does nothing at all.

[Gnikolov (gnikolov)]

Clicking "open" in the dialog manager, after a file has been downloaded, does
nothing in Linux. In Windows it does actually opens the file with the registered
program.

In the download manager, clicking the directory name that goes after "All files
downloaded to" does nothing in Linux. In Windows it actually opens the folder
that contains all downloads.

[Gnikolov (gnikolov)]

I installed Suse 9.2 and it seems to work now. I guess it was a problem only
with Suse 9.1. Sorry about the double post before.

[Johann Petrak (johann-petrak)]

I just tried this and realized it is implemented in a totally flawed way: it
started nautilus(!), actually forcing a Gnome desktop on top of my KDE desktop.
This is an odd and bad idea: FF does have a built-in way to show local
directories with the file:/// protocol. The nautilus program or Gnome might not
even be installed on the system FF is running on.

FF should not rely on external programs to do that and if it supports that as an
additional option, it should allow the user to easily which program gets started
and how.

[Gnikolov (gnikolov)]

(In reply to comment #4)
You are right. It starts nautilus even though it is not my default browser.
There is no way to make it start in konqueror. If nautilus is not installed it
doesn't work at all.

[Gervase Markham (gerv-mozilla)]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/

[Peter-vanderwoude (peter-vanderwoude)]

I'm not sure you can't do this with the Launchy extension

[Dsotm (dsotm)]

(In reply to comment #2)
> I'm not sure you can't do this with the Launchy extension
You can't.

This bug still exists. Even with a custom filemanager defined in Windows, "open containing folder" in FF 2.0 still uses Windows Explorer.

[Stephanie Daugherty (sdaugherty-deactivatedaccount)]

Confirming as feature request.

[Diorser (diorser)]

Bug still alive 3 years later.
See bug 270547.

[Shawn Wilsher (sdwilsh)]

*** Bug 270547 has been marked as a duplicate of this bug. ***

[Diorser (diorser)]

Well, there is in fact a very good loader in KDE called KGet usually very well appreciated.
A script has been proposed some time ago to replace the unusable Firefox loader in KDE with KGet.
It partially works with Fx 2, because probably developed for Fx 1.5.

Sure a small update of this patch would be a fair proposal to KDE users.

See:
KGet integration for Mozilla and Firefox
http://www.polinux.upv.es/mozilla/mejoras.php?idioma=en

Script:
http://www.polinux.upv.es/mozilla/improvements/kget4mozilla/kget4mozilla-0.2.sh

[Manuel López-Ibáñez (manuellopezibanez)]

Binary package hint: firefox

Tools->Downloads-> (Right click)->Open containing folder

Result: Nothing happens (not even an error).
Expected: An error, a dialog asking to choose a file manager or just konqueror showing the folder.

Fix: add the following line to prefs.js
user_pref("network.protocol-handler.app.file", "konqueror");

ProblemType: Bug
Architecture: i386
Date: Fri Aug 17 12:54:22 2007
DistroRelease: Ubuntu 7.04
Package: firefox 2.0.0.5+1-0ubuntu1
PackageArchitecture: i386
SourcePackage: firefox
Uname: Linux localhost 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux

[Manuel López-Ibáñez (manuellopezibanez)]

Even better would be to use the "--select" option of konqueror to focus on the relevant file as FF does in Windows, but I don't see how to make that work with prefs.js syntax.

Why Firefox developers hate Linux so much and KDE in particular? :-(

[D. Brodzik (amyrose)]

This should detect whether KDE is running via the DESKTOP_SESSION variable (seeing if it says "kde") and if so, it should use "kfmclient exec" to open the containing folder, making it use KDE's default file manager. But apparently Mozilla only cares about GNOME.

[Diorser (diorser)]

It seems the conclusion of this bug is simply....
in KDE, better use Konqueror.

[Jürgen 'jiha' Harter (jiha-bugzilla)]

This is related to Bug 386519. Adding dependency.

[Jani Monoses (jani)]

it is not working in xubuntu 8.04 either. Is firefox not using xdg-open to open a folder? Is nautilus hardcoded now in upstream or ubuntu patches? IIRC this used to work in xubuntu with thunar in 7.10

[TWO (two)]

No joy in Kubuntu 8.04 KDE 3.5.9 either. It's a tad inconvenient really and this has been a problem for a while now! Two distributions have gone by and this has persisted!

[Alexander Sack (asac)]

this needs to be properly filed upstream ...

 affects firefox
 status incomplete

i assume this is a firefox 3 issue

 affects ubuntu/firefox-3
 status confirmed

unfortunatley, ffox 2 wont see any non-critical fixes anymore

 affects ubuntu/firefox
 status wontfix

[TWO (two)]

I'm not sure whether it's a Firefox 3 issue myself, but I can confirm that it's an issue with Firefox 2. I reinstalled it when I upgraded to Kubuntu Hardy Heron and the problem still persists. It would be nice if this was fixed for Firefox 2 though since I'm not sure when Firefox 3 is going to stop being beta and then there's the fact that anyone using (K)(X)Ubuntu 8.04 is stuck with this version until October.

[John Vivirito (gnomefreak)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TWO wrote:
| I'm not sure whether it's a Firefox 3 issue myself, but I can confirm
| that it's an issue with Firefox 2. I reinstalled it when I upgraded to
| Kubuntu Hardy Heron and the problem still persists. It would be nice if
| this was fixed for Firefox 2 though since I'm not sure when Firefox 3 is
| going to stop being beta and then there's the fact that anyone using
| (K)(X)Ubuntu 8.04 is stuck with this version until October.
|
Firefox-2 will not see a fix for this since it is nearing EILS and at
this point Firefox-2 will only see very Important fixes for example any
and all security risks firefox-2 wont load (do to upstream error not
profile error) things like that. I wont say that this bug isnt important
im just saying this is what is planed at this point. Looks like
Firefox-3 is very near release releasing EC1 and if not blockers found
they will push that to final in a few weeks.

Yes this is a Firefox bug/feature not sure which at the moment but i see
it in Firefox-3 b5 and rc1 both of which are our(Ubuntu-MozillaTeam) builds

Im gonna wait and look at a few things to see if we can ship the fix, I
will ask our head maintainer about what he would like to do. Thiis can
be fixed in Firefox-2 in Intrepid but we are thinking about removing
Firerfox-2 just before Intrepid release if we see that Firefox-3 is
doing good standing on its feet.

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILK6bqig4QTwcPCoRApRsAJ9fnf5E2q8w5SyLMcFR1ObAqDb90ACdEffZ
PreH8xieGyPUxtJrZpw0TSs=
=PNwD
-----END PGP SIGNATURE-----

[Alexander Sack (asac)]

On Thu, May 15, 2008 at 06:35:39AM -0000, TWO wrote:
> I'm not sure whether it's a Firefox 3 issue myself, but I can confirm
> that it's an issue with Firefox 2. I reinstalled it when I upgraded to
> Kubuntu Hardy Heron and the problem still persists. It would be nice if
> this was fixed for Firefox 2 though since I'm not sure when Firefox 3 is
> going to stop being beta and then there's the fact that anyone using
> (K)(X)Ubuntu 8.04 is stuck with this version until October.
>

The fact that firefox 3 is called "beta" doesn't mean that its
instable or something. We put firefox 3 intentionally as default as
our testing showed that its ready for prime time.

BTW, mozilla thinks so too:

  http://www.reuters.com/article/technologyNews/idUSN2041266520080320

Please test if this an issue for you in ffox 3

Firefox 2 wont see any non-critical fixes. Marking accordingly

 affects ubuntu/firefox
 status wontfix

 - Alexander

[Diorser (diorser)]

 Bug 386519 is mixing gnome discussion.

To summarize:
With Firefox installed in KDE (not gnome), when right-clicking a download in the download manager, the option "open containing folder" does nothing at all.
(It should not take 4 years to check/confirm this bug).

[darkmethod (darkmethod)]

see:
http://rubylution.ping.de/articles/2007/09/11/open-containing-folder-in-firefox-under-linux

Open Containing Folder in Firefox under Linux

Posted by flori on 09/11/2007

After Downloading a file in firefox and right-clicking on the filename in the download manager, you can choose the popup menu entry "Open Containing Folder". This should open a filebrowser for the directory this file was saved in. I have to admit, that this never worked for me under Linux, only under MacOS X and under Windows. I assume the reason for this is, that you have a lot of options under Linux, but no general default for a file manager. Firefox did never show a very smart reaction (and only displays an error) if no filebrowser could be found: Perhaps asking me what to do would be a good idea?

I finally couldn't take it anymore and researched how to configure this feature. I wanted XFCE4's file manager Thunar to be opened, so this is what you have to do: Open the about:config dialog in you location toolbar (or pick it from the Help menu). Now right click onto the configuration entry list, and choose New -> Boolean from the popup menu. Create the following two entries and set them both to true:

network.protocol-handler.expose.file = true (Boolean) network.protocol-handler.external.file = true (Boolean)

Now choose New -> String from the popup menu, and set the value to thunar:

network.protocol-handler.app.file = thunar (String)

This will start thunar with containing directory (with a file:// url) as an argument. You can as well use nautilus or konqueror or whatever here. Another possibility is to use open, which would cause firefox itself to open the directory as a file:// url.

[panzi (grosser-meister-morti)]

This bug is really annoying for KDE users. Most fix it by making a link called "nautilus" linking "konqueror". But that's an ugly hack. Why not just use xdg-open (if it exits)? This will open the right app for the currently running desktop environment. There is no reason at all why this xdg-open should not be used under *nix. I for myself did an even uglier hack to tell Firefox to use Konqueror, see: http://twoday.tuwien.ac.at/pub/stories/316660/

Just running xdg-open file:///path/to/the/dir/ should do the whole trick. No special support for any DE needed.

[Manuel López-Ibáñez (manuellopezibanez)]

This also happens in Firefox 3 in Kubuntu Hardy.

Creating a symlink from dolphin to nautilus does not fix this. Creating a network.handler-protocol.app.file neither.

[Manuel López-Ibáñez (manuellopezibanez)]

Bug 452626 is a duplicate of this one.

[Manuel López-Ibáñez (manuellopezibanez)]

This still does not work in Kubuntu Hardy with Firefox 3

[Manuel López-Ibáñez (manuellopezibanez)]

The workaround above doesn't work for me either. I don't get any warnings or errors or any output in console.

[Manuel López-Ibáñez (manuellopezibanez)]

There is a word-around here but it seems too invasive, so I haven't tested it. I don't want to break my profile.

http://twoday.tuwien.ac.at/pub/stories/316660/

[Manuel López-Ibáñez (manuellopezibanez)]

There is no information requested, so this cannot be Incomplete.

[Jürgen 'jiha' Harter (jiha-bugzilla)]

(In reply to comment #14)
> Bug 452626 is a duplicate of this one.

It is not. As I read that bug /something/ happens on KDE with dolphin now. The issue there is that the filemanager does not show the right directory.

Could somobody with a plain KDE with dolphin please sort the things out? The 'open containig folder' stuff works fine on gnome but not on KDE. But what's the real issue? Fault of KDE or $Mozilla?

[drewster1829 (arruud)]

The workaround darkmethod posted is probably for Firefox 2, based on the date of the article. I tried it with Firefox 3 and Ubuntu Hardy, and it does not work.

[Alexander Sack (asac)]

also referenced this bug now in the comments section of https://wiki.ubuntu.com/Firefox3KDEIntegrationIntrepid

[Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount)]

This bug is a really ugly one !
In my case cervisia (KDE CVS tool) is startet which just reports an error.
It seems this happens because the entry inode/directory=... in /applications/mimeinfo.cache lists that as the first one (which should not matter).
I tried this with a clean user profile.
No nautilus is installed here.

xdg-open file:///... opens dolphin here as intended.
I think firefox should better use this as stated in
https://bugzilla.mozilla.org/show_bug.cgi?id=258085#c5

ArchLinux 686
KDE 4.2.0
Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
(Binary downloaded from mozilla.org not from ArchLinux)

[Ahmad Samir (ahmad.samir)]

It seems that firefox (and most GTK apps running in kde3 and kde4, such as file-roller and catfish) don't respect kde's file type associations. Instead firefox looks at:
- /usr/share/applications/defaults.list : this is, AFAICT, a static file created when you first install the system

AND

- /usr/share/applications/mimeinfo.cache : this is a dynamically changing file, it's changed when you install a new programme. So for example it will change when you install nautilus or pcmanfm in kde.

Firefox will look first at defaults.list but will give preference to mimeinfo.cache. So if the same entry (e.g. inode/directory) exists in both defaults.list and mimeinfo.cache firefox will take whatever mimeinfo.cache says.

You can manually make "Open containing folder" use your favourite programme by editing /usr/share/applications/mimeinfo.cache . Basically you need to edit the "inode/directory=" entry and put the desired application's .desktop name up front, so to use dolphin, change it to:

inode/directory=kde4-dolphin.desktop;

Notice the extra kde4 in kde4-dolphin.desktop , this is necessary because dolphin.desktop is not in the same folder as mimeinfo.cache; mimeinfo.cache is in /usr/share/applications while dolphin.desktop is in /usr/share/applications/kde4 . If a .desktop file is going to be used and it exists in /usr/share/applications then use its plain name without a prefix.

To use konqueror instead of dolphin it should be:
inode/directory=kde4-kfmclient_dir.desktop;

Be aware though that /usr/share/applications/mimeinfo.cache will be changed automatically when you install a new *relevant* programme/file manager such as nautilus. However you can maintain a local copy that will not be changed when you install anything else, put a copy of defaults.list and mimeinfo.cache in your home folder in ~.local/share/applications.

The problem that existed with dolphin not using the right folder url has vanished in kde 4.2. The problem was that by default the command line in dolphin.desktop was "dolphin %i -caption "%c" %u" and that didn't work in kde 4.1.2 but it works OK with the same command line in KDE 4.2 (I wouldn't take that to the court, though :) ) I know for sure that it's working OK in kde 4.2 .

My system specs:
KDE 4.2
Firefox 3.0.5

A wild guess is that in gnome there's gnome-settings-manager that makes whatever file associations you change in Gnome get applied when you log into Gnome, but gnome-settings-manager isn't run in KDE.

[Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount)]

(In reply to comment #17)

Thank you for explaining all this.

I found another workaround somewhere else:
Edit cervisia.desktop and kfmclient-dir.desktop located in /usr/share/applications/ and add a line "OnlyShowIn=KDE;"
After update-mime-cache firefox will use dolphin.

[Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount)]

(In reply to comment #18)
Sorry, I meant /usr/share/applications/kde4/

[Kurt J. Bosch (kujub-deactivatedaccount)]

Hi,
this problem affects other distributions.

Please consider to vote for this upstream.
https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=266600#vote_266600

[Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount)]

This seems also to be a problem with Xfce.

I worked around this now with this command:
xdg-mime default Thunar-folder-handler.desktop x-directory/normal

For KDE something like that one can be used:
xdg-mime default dolphin.desktop x-directory/normal

For GNOME there seems to be a different one named x-directory/gnome-default-handler which could be set to nautilus-folder-handler.desktop.

What xdg-mime does is simply writing a line like
 x-directory/normal=dolphin.desktop
into the file ~/.local/share/applications/defaults.list.

Custom desktop files located in ~/.local/share/applications/ also work with this.

I found all this by some googling and be trial and error. Unfortunately there seems to be no documentation about this.

ArchLinux 686
Xfce 4.6.0
KDE 4.2.1
GNOME 2.24
Firefox 3.0.7 GranParadiso

[Henrique Abreu (hgabreu)]

I solved this by associating the file manager (thunar in my case) to "file" 'Content Type' on firefox preferred applications.

Regards,
Henrique Abreu

Firefox 3.0.7
Xfce 4.4.2
Debian Squeeze

[Kokoko3k (kokoko3k)]

firefox version: 3.1b3
De: Kde 3.5

I'm using archlinux and i haven't any problem.

I think it's just a matter of mimetypes (located at: ~/.mozilla/firefox/ProfileName/mimeTypes.rdf )
Attached you'll find mine which uses /usr/bin/xdg-open, but if "file" is defined, you can easilly go through:
Menu Edit, Preferences, Applications, scroll down until "file", and select something useful for you in the second column.

[racerraul (racerraul)]

I got this to work by following the instructions on the following links, but with a few changes.
http://rubylution.ping.de/articles/2007/09/11/open-containing-folder-in-firefox-under-linux

Open About:Config and add the following entries
network.protocol-handler.expose.file = true (Boolean)
network.protocol-handler.external.file = true (Boolean)

Notice that in the following entry I am actually telling thunar to open my downloads assigned folder.
network.protocol-handler.app.file = thunar ~/Downloads (String)

I then tested it and FF prompted me for the application to use.
I then navigated to /usr/bin/thunar hit OK and selected the check mark to remember my choice.

Hope that works for some of ya. But that got it to work for me.

[Ahmad Syukri Abdollah (syockit)]

racerraul, what happens when you double click on the file in the Download Manager list instead of selecting "Open Containing Folder"? Do you get it to open with the associated program, or do you also get it opened with Thunar?

In my case, when I tried opening the containing folder the first time,
- Firefox asked me to select the program to use, naturally I'd select /usr/bin/nautilus for my GNOME environment.
- I also marked the checkbox "Remember my choice for file links".
Then it will open Nautilus for any file I right-clicked and clicked "Open Containing Folder". But the side effect is, for all files I try to open (either by double clicking, or right click and select "Open", it will still try to open with Nautilus, coming up with error "the location is not a folder".

I wonder why opening a folder is treated as opening a file link in Firefox?

[racerraul (racerraul)]

I just tried it after I downloaded a BIOS update file... dos.exe type...
It attempted to run it with wine...

perhaps if you don't have any file types associated with the file it will do that? Just guessing.
I also tried a .pls file from di.fm and it opened with xmms (my player of choice).

[Kevin Brosnan (kbrosnan)]

*** Bug 446204 has been marked as a duplicate of this bug. ***

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/133133

[MarcRandolph (mrand)]

Since Mythbuntu ships with xfce, this affects anyone that does a default Mythbuntu install and tries to use Firefox. Not the most common Mythbuntu use-case, but plenty of people do it. Confirmed on 9.10 Beta.

[dewert (dewert)]

Not entirely sure if this is related, but I had the exact problem described at http://bbs.archlinux.org/viewtopic.php?id=69035 and the solution there fixed it.

What happened there was that firefox was using EasyTag instead of konqueror/dolphin.

Now, while this is slightly different, the fact is that firefox seems to be using /usr/share/applications/mimeinfo.cache for information about file associations, because when I removed EasyTag from there, Firefox started using Dolphin.

Oddly, the next option (which I didn't delete) was Thunar, but this, apparently, was ignored.

[Mozilla-bugs-thequod (mozilla-bugs-thequod)]

@Kurt (comment #20):
unfortunately this does not appear to work for Ubuntu/Kubuntu.

I have added those entries to ~/.local/share/applications/defaults.list:
  inode/directory=dolphin.desktop
  x-directory/normal=dolphin.desktop

[Ahmad Samir (ahmad.samir)]

Ideally dolphin.desktop is inside /usr/share/applications/kde4/ , so you have to prefix the entry with kde4-, so it becomes:
x-directory/normal=kde4-dolphin.desktop

Check where dolphin.desktop is located, I don't use ubuntu so I don't know where it's exactly on your system.

Another thing I noticed is I have an entry named "file" in Edit> preferences> applications, selecting "use other" and then selecting /usr/bin/xdg-open, makes it open in the DE's preferred file manager. On a fresh profile I don't see the "file" entry, I don't know what creates it...

[Daniel Hahler (blueyed)]

I've tried adding the stanza for "file" proposed by Kokoko3k in comment #17:
  <RDF:Description RDF:about="urn:scheme:externalApplication:file"
      NC:prettyName="xdg-open"
      NC:path="/usr/bin/xdg-open" />
to mimeTypes.rdf in the new test user profile, without any luck.

Also, "file" does not appear in the list of applications, as mentioned in the same comment (for the new profile). It appears in my regular users profile however (but seems to apply to unknown files also).

After all, it should boil down to make Firefox call xdg-open when opening files, and folders.
I've not found the place to patch this though, but the path goes via mozilla/toolkit/mozapps/downloads/content/downloads.js:
f.reveal() gets called to show the folder, but I could not find where "reveal" is defined, nor if it goes via the catch block.
Here's the related code from the firefox source:
function showDownload(aDownload)
{
  var f = getLocalFileFromNativePathOrUrl(aDownload.getAttribute("file"));

  try {
    // Show the directory containing the file and select the file
    f.reveal();
  } catch (e) {
    // If reveal fails for some reason (e.g., it's not implemented on unix or
    // the file doesn't exist), try using the parent if we have it.
    let parent = f.parent.QueryInterface(Ci.nsILocalFile);
    if (!parent)
      return;

    try {
      // "Double click" the parent directory to show where the file should be
      parent.launch();
    } catch (e) {
      // If launch also fails (probably because it's not implemented), let the
      // OS handler try to open the parent
      openExternal(parent);
    }
  }
}

[Mozilla-bugs-thequod (mozilla-bugs-thequod)]

Yes, dolphin.desktop is in /usr/share/applications/kde4/, but adding the "kde-" prefix still does not make Firefox use it.

Additionally, I've tried using xdg-open for the "file" type in Firefox' preferences, but "Show Containing Folder" still opens Nautilus.

(directly calling "xdg-open /some/dir" works)

It seems like Ubuntu makes it even worse (for me) than stock Firefox - I should focus on the bug report over there (https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/133133).

[kanat (kanat2)]

Hi, I noticed in my Easytag problem this disconnect in mime types:

Firefox prefers x-directory/normal
before checking inode/directory

KDE can't access x-directory/normal
can only set inode/directory

  grep directory /usr/share/applications/mimeinfo.cache

I use Mandriva 2009.1. Under Configure Your Desktop/System Settings/Advanced/File Associations
I can only change inode/directory, can't access x-directory/normal.

On Linux, Firefox should not prefer x-directory/normal MIME type to open folders.
It should check inode/directory first.

[Kevin Brosnan (kbrosnan)]

*** Bug 555007 has been marked as a duplicate of this bug. ***

[Micah Gersten (micahg)]

Resetting to Triaged in firefox as we moved to an unversioned source package.

[Saulantolinez-ruiz (saulantolinez-ruiz)]

*** I think bug 555007 is not a duplicate of this bug. I unmarked it as duplicate of this one of here. Also, I found a workaround for it. ***

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

user_pref("network.protocol-handler.app.file", "konqueror");
does not appear to work with FireFox 4 (beta 12).

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

FWIW
xdg-open /tmp/
works as expected (loads Dolphin) , so this is a FireFox bug...

[Don Rhummy (donrhummy)]

I am getting this with Firefox 4, openSUSE 11.3. It attempts to use EasyTag and none of the changes I make in about:config help, nor did changing "inode/directory" and "x-directory/normal" in mimeinfo.cache or mimeapps.list.

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

Under Natty, I get Dolphin opening now. Woot!

[Matěj Cepl (mcepl)]

*** Bug 506587 has been marked as a duplicate of this bug. ***

[rb.eng (rb-engch)]

Under Oneiric I had a similar problem where the "open containing folder" would start up the software center. The solution I found was to edit the following file:

    ~/.local/share/applications/mimeapps.list

in my case there was a line in the [Added Associations] section for inode/directory which pointed to software center:

   inode/directory=<something>

after deleting this line and saving the file and trying "open containing folder" it worked correctly in nautilus. Looking again at the above file I noted in the section [Default Associations] the line:

   inode/directory=nautilus-folder-handler.desktop

Hope this helps find a work around for you.

[Psychonaut (psychonaut)]

I have two systems with Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 installed. One of them is running on KDE 4.6.0 on openSUSE 11.4, and the other KDE 4.9.5 on openSUSE 12.2. On the first one, "Open containing folder" correctly opens the directory using the default KDE file manager, Dolphin. On the second one, the correct directory is opened using the default Gnome file manager, Nautilus. No idea why one system correctly uses Dolphin but the other incorrectly chooses Nautilus.

[Ahmad Samir (ahmad.samir)]

(In reply to Tristan Miller from comment #30)

Try this:
- Create ~/.local/share/applications/defaults.list (edit it if it already exists)
- Put this in it:

[Default Applications]
inode/directory=kde4-dolphin.desktop;

save it and try "open containing folder" again.

[Psychonaut (psychonaut)]

(In reply to Ahmad Samir from comment #31)

Yes, that fixes the problem on the openSUSE 12.2 system.

[Bugzilla-tf (bugzilla-tf)]

*** Bug 868768 has been marked as a duplicate of this bug. ***

[Alex Palecek (alex-palecek)]

I was having a similar problem with Firefox on Linux Mint 13 "Maya" MATE. For some reason, SoundConverter was associated with this MIME type, so that when I tried to "Open Containing Folder" in Firefox, it would invoke SoundConverter for any download.

By changing the entries in
     ~/.local/share/applications/mimeapps.list
from :
     inode/directory=soundconverter.desktop;
to :
     inode/directory=caja.desktop;

functionality was restored.

Thanks!

[Thomas Sisson (thomas-sisson-1)]

Since I am not a programmer, I cannot submit a patch. However, can't someone simply replace whatever is opening Nautilus with xdg-open? You don't even have to know how it works or where the files are.

Just to be clear though, anything involving xdg uses XDG standards. If one is curious, or simply wants or needs to know the standard, check out multiple publications at freedesktop.org.

I understand that Mozilla has abandoned Qt, but that does not mean that Linux distributions of Mozilla software should be Gnome specific. The point of the XDG standard is that anything following it should work for any desktop environment that follows it. Both Gnome and KDE follow those standards.

[PhobosK (phobosk)]

(In reply to Tristan Miller from comment #30)
> I have two systems with Mozilla/5.0 (X11; Linux x86_64; rv:19.0)
> Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 installed. One of them is
> running on KDE 4.6.0 on openSUSE 11.4, and the other KDE 4.9.5 on openSUSE
> 12.2. On the first one, "Open containing folder" correctly opens the
> directory using the default KDE file manager, Dolphin. On the second one,
> the correct directory is opened using the default Gnome file manager,
> Nautilus. No idea why one system correctly uses Dolphin but the other
> incorrectly chooses Nautilus.

Probably on one of the systems you have Nautilus installed and on the other you don't.....

Anyway... This is a very annoying bug that is still handled very badly...

This bug is still valid for FF 29.0.1 in Linux.

It turns out that FF (tested on 29.0.1 on Gentoo) when built with dbus support has a wrong way to "Open containing folder".
It first calls (instead of checking if exists first and then calling) org.freedesktop.FileManager1 on the session bus and thus if nautilus is installed it is started as "/usr/bin/nautilus --no-default-window" and in this way FF doesn't honor the XDG at all.

So for now a workaround is either to delete the /usr/share/dbus-1/services/org.freedesktop.FileManager1.service or change its Exec to "dolphin" (if you are under KDE, though that may have implications 'cause dolphin doesn't register any org.freedesktop.FileManager1).

It needs fix definitely or at least an option to choose in FF preferences

Please see also bug #258085

[Ahmad Samir (ahmad.samir)]

(In reply to PhobosK from comment #36)

I've seen the same issue in Fedora. My workaround was to "sabotage" the org.freedesktop.Filemanager1 dbus service by creating ~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service and changing the Exec line to e.g. /usr/bin/false or /usr/bin/true; this is better since it's persistent and isn't affected by system updates... etc. This makes Firefox use whatever file manager I set in ~/.local/share/applications/defaults.list (see comment #31).

Changing Exec to /usr/bin/dolphin somehow made "open containing folder" open the file manager, but the firefox UI gets sort of blocked/hung for a while, probably because firefox tries to query the capabilities of org.freedesktop.FileManager1 via dbus first, (just a guess).

[..]

[Ahmad Samir (ahmad.samir)]

Add to the above (about changing Exec to /usr/bin/dolphin) is that I get two dolphin windows opened, one at ~ and the other to the actual folder containing the file from the download manager/library, until the second window is opened Firefox is hung.

[Ahmad Samir (ahmad.samir)]

I first hit the org.freedesktop.FileManager1 issue a couple of months ago, so my memory is a bit hazy on the issue. In the workaround I posted in comment#37 the Exec line has to be /usr/bin/false, otherwise there's a delay before the file manager is opened. Most likely because /usr/bin/false returns an exit code 1.

[systemhealer (system-healer)]

This bug has been open for 10 years. LOL.

Maybe I'm oversimplifying things in my head, but from a design perspective it sure would be nice if there were a "Folder" file type in the Applications settings. Since there are dozens of file managers for GNU-Linux, and several mainstream desktop environments to choose from, I would certainly not expect Firefox to read my mind as to what my file manager preference is.

[kolAflash (colaflash)]

Currently Firefox 33 is using org.freedesktop.FileManager1 to open a filemanager. Sadly, only Nautilus implements this interface. It's not just opening a filemanager but also bidirectional communication with the caller.

https://bugzilla.opensuse.org/show_bug.cgi?id=904229#c2

Is Firefox using this bidirectional communication feature or something else, special from org.freedesktop.FileManager1 ?

If Firefox isn't using the special features of org.freedesktop.FileManager1, just change Firefox to use "xdg-open $DIRECTORY" to open a filemanager or to look up the default filemanager in:
~/.local/share/applications/mimeapps.list (has priority)
/usr/share/applications/mimeinfo.cache

If Firefox uses special features from org.freedesktop.FileManager1:
In a perfect world, Firefox should check if Nautilus is set as the default filemanager. E.g. running "xdg-mime query default inode/directory" which checks the files:
~/.local/share/applications/mimeapps.list (has priority)
/usr/share/applications/mimeinfo.cache

Alternatively, Firefox could check if DESKTOP_SESSION is set to "gnome".
I wouldn't suggest to check for DESKTOP_SESSION=KDE, because there are a lot of other desktop environments which also use other filemanagers then Nautilus.

If the results is negative (depended on which strategy was chosen), Firefox should use the default filemanager (either the on set by the system or set by the user). This can be done by running "xdg-open $DIRECTORY" or looking up the default filemanager in:
~/.local/share/applications/mimeapps.list (has priority)
/usr/share/applications/mimeinfo.cache

[Rulatir (rulatir)]

I am starting to suspect developer malice here.

This bug is not fixed but **hardened** over the years: loopholes that enable workarounds get fixed instead. I wonder when Firefox will actually start reinstalling nautilus from the repos when it detects that I have deleted the binary and symlinked it to dolphin (because nothing else works at this point).

[kolAflash (colaflash)]

Everyone who worries about this bug, please click the little "vote" button at the top and vote for this bug to be solved!
Every vote counts! ;-)

[Uqbar (uqbar)]

I think more about stupidity that malice.
Firefox is not a Qt/KDE application but rather a GTK+ one. Some packager thinks that if you use Firefox you obviously are willing not only to install the full GNOME bag of stuff, but also ditching KDE in favor of it.
When I install Firefox, I am not asking for anything but Firefox. If I have program X to browse directories, I wish I keep it as it is.
Firefox package(r) instead thinkis he knows more than I do.

[Uqbar (uqbar)]

Forget about bugs filed at Mozilla.
The notorious bug no.915 (https://bugzilla.mozilla.org/show_bug.cgi?id=915) was filed along with HTMLv4.01 standard.
They just sat down and wait until HTML5 became a standard and that bug went out of meaning.

[Manuel López-Ibáñez (manuellopezibanez)]

(In reply to kolAflash from comment #43)
> Everyone who worries about this bug, please click the little "vote" button
> at the top and vote for this bug to be solved!
> Every vote counts! ;-)

The main purpose of voting is to avoid the annoying and useless "Me too!" messages: see bug 374002. Votes do not influence which bugs get fixed.

(In reply to Szczepan Hołyszewski from comment #42)
> I am starting to suspect developer malice here.

That seems uncalled for. Firefox developers working on Linux issues are very few and hard-working. They need more love and support and not users throwing accusations. Also, if you honestly want to see support of Linux continued, you are shooting yourself in the foot with such a comment: Which developer wants to work on supporting an OS when users of that OS accuse them of malice? Scaring developers away is not the way to improve such support!

The reality is that there are very few Firefox developers that use GNU/Linux, and all of them probably use GNOME/GTK. GTK developers have contributed at lot to Mozilla/Firefox, whereas KDE has its own browser (Konqueror and now Rekonq). The people that have tried to improve Firefox on KDE have done so by creating add-ons or distribution-specific patches. This is a quick way to get results but tends to bitrot and break sooner or later.

The *only* way Firefox support for KDE will improve is if people using Firefox on KDE join Firefox development and do it. If you cannot do it yourself for lack of time or skills, create a kickstarter and hire a developer that can. If you do not have skills, money, or time, and you cannot figure out another way to help, then resign yourself in silence because it will probably get worse. Attacking developers, whining and useless comments (mine ones included, unfortunately) only make developers *less* inclined to follow bug reports about KDE.

[Ahmad Samir (ahmad.samir)]

(In reply to M Lopez-Ibanez from comment #44)
> (In reply to Szczepan Hołyszewski from comment #42)
> > I am starting to suspect developer malice here.
>
> That seems uncalled for.

I agree that this is a bit too much, no malice involved; I think it's mostly due to lack of time/resources....etc.

> Firefox developers working on Linux issues are very
> few and hard-working.

Any official stats/references about how many Firefox devs are actually working on Linux?

> They need more love and support and not users throwing
> accusations. Also, if you honestly want to see support of Linux continued,
> you are shooting yourself in the foot with such a comment: Which developer
> wants to work on supporting an OS when users of that OS accuse them of
> malice? Scaring developers away is not the way to improve such support!
>
> The reality is that there are very few Firefox developers that use
> GNU/Linux, and all of them probably use GNOME/GTK.

Again any references/stats?

> GTK developers have
> contributed at lot to Mozilla/Firefox,

Well, the most obvious reason is that Firefox is built on GTK+*. I think if Firefox was built on Qt it would have gotten a lot of contribution from Qt devs, that's the nature of using a toolkit to build your software...

> whereas KDE has its own browser
> (Konqueror and now Rekonq).

That's not really a point since GNOME has its own browser too, it's called Epiphany, a WebKit based browser (it's been renamed to "Web" lately https://wiki.gnome.org/Apps/Web/).

> The people that have tried to improve Firefox on
> KDE have done so by creating add-ons or distribution-specific patches. This
> is a quick way to get results but tends to bitrot and break sooner or later.
>

IIRC those changes were submitted as bug reports upstream but were rejected hence the distribution patches/addons.

> The *only* way Firefox support for KDE will improve is if people using
> Firefox on KDE join Firefox development and do it. If you cannot do it
> yourself for lack of time or skills, create a kickstarter and hire a
> developer that can. If you do not have skills, money, or time, and you
> cannot figure out another way to help, then resign yourself in silence
> because it will probably get worse.

This issue isn't KDE specific; the issue here is that there's no easy was to make Firefox use whatever file manager you set as the default in Linux. Even under GNOME you'd hit the same problem if you want to use a file manager other than Nautilus; you can configure GNOME to use whatever file manager you want but Firefox would ignore those settings.

Firefox could use xdg-open (this was suggested in previous comments in this report) which is supposed to be distro-agnostic; given xdg* isn't perfect but it's better than using a dbus method that's only implemented by Nautilus under GNOME.

> Attacking developers, whining and
> useless comments (mine ones included, unfortunately) only make developers
> *less* inclined to follow bug reports about KDE.
True, insulting devs isn't good any which way one thinks about it. But I think frustration can lead to such accusations flying around; the open-containing-folder feature misbehaving for anything other...

[Rulatir (rulatir)]

New discovery: uninstalling nautilus "solves" the problem.

Here's my prophecy: the patch that will finally fix this bug will consist of deletions only.

[emr (emrecio)]

Yeah, I am going to try and uninstall caja (the app that is causing me grief with firefox). I am trying to run open files dialog on firefox on Fedora 21 / KDE.

Next step is to just switch to chrome or something.

[Manuel López-Ibáñez (manuellopezibanez)]

I cannot reproduce this bug anymore in 14.04 and the work-around is not needed. Thus, I am closing it. If you are still seeing it, please open a new report describing your setup. Is obvious that the info provided here is very outdated.

[Manuel López-Ibáñez (manuellopezibanez)]

This works for me in Kubuntu 14.04 without any additional configuration or work-around. I don't have nautilus installed.

[emr (emrecio)]

If you have nautilus installed this becomes a problem because firefox wants to use dbus engine. Firefox apparently uses the dbus engine first to launch org.freedesktop.FileManager1 which nautilus is currently the only app that gets launched/used this way. You have to install your own org.freedesktop.FileManager1.service file in ~/.local/share/dbus-1/services

Also look to see if you have other FileManager1 filemanagers registered to dbus. I had two custom Nemo and Caja, and i just copied those files from their default location to my home directory location and changed the Exec. Firefox gives up, and goes the xdg route - which I thought was supposed to be the standard. This is a complete mess.

This link describes the process in detail: http://debian.distrosfaqs.org/debian-user/iceweasel-and-dolphin/ and https://bugzilla.mozilla.org/show_bug.cgi?id=1106916

[U279673 (u279673)]

(In reply to Moltres Rider from comment #49)
> This is also a problem on FF39 on Windows 7

Works fine for me on FF40 Windows 7 Ultimate 64-bit

[Timothy-holt123 (timothy-holt123)]

It does absolutely nothing for me in Windows 7 Ultimate 64-bit. It has been broken for me for several months. Using latest version (FF43). Why doesn't it work anymore for me?

[Antoine-mechelynck-gmail (antoine-mechelynck-gmail)]

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 SeaMonkey/2.43a1"
ID:20160101003002 en-US
c-c:ca2c0fd7c80d758f98954ca7789cb59b3f8ad2d1
m-c:22f51211915bf7daff076180847a7140d35aa353

Both KDE and Gnome libraries present on the system. The X11 login screen is presented by KDE kdm (display manager) but IIUC the window manager is Gnome.

When I click "Open containing folder" it opens in Dolphin (by KDE). Some people mentioned Nautilus, and that is installed here, but doesn't open.

Note that I'm using the "new dowload manager" which comes built-in with SeaMonkey and used to be available as an extension for Firefox but isn't anymore.

So I see two possibilities:
- Maybe I'm not seeing it because SeaMonkey's "new download manager" is better?
- Maybe I'm not seeing it because I've got Dolphin _in addition_ to Nautilus?

In any case, here it does open the KDE file manager, even though my desktop (but not my X11 login screen) is supposedly Gnome and my SeaMonkey is built on Gnome3.

[oid8 (oid8)]

great suggestion to sabotage gnome! see also: https://polywogsys.livejournal.com/309405.html

https://support.mozilla.org/en-US/questions/1263440#answer-1234152

https://forum.kde.org/viewtopic.php?f=224&t=143366&p=419442#p419442

[Graham Perrin (grahamperrin-gmail)]

> Open containing folder function does nothing (KDE)

Is this still an issue?

Compare with e.g. bug 893799 …

[Release-mgmt-account-bot (release-mgmt-account-bot)]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 30 votes.
:mak, could you consider increasing the bug severity?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#severity_underestimated.py).

[Autonag-nomail-bot (autonag-nomail-bot)]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

[9-peter-e (9-peter-e)]

(In reply to Graham Perrin from comment #53)
> > Open containing folder function does nothing (KDE)
>
> Is this still an issue?
> …

For me at least this is still an issue when using Konqueror as default filemanager. If using Dolphin as the default filemanager, *and* it responds to the `org.freedesktop.FileManager1` dbus interface (this is the default setup in KDE AFAIK), Dolphin gets used appropriately and everything is fine.

Having Dolphin installed and Konqueror as default filemanager will result in Dolphin being used.

In KDE with Konqueror as default filemanager and multiple other filemanagers installed that have a `.service` file for the `org.freedesktop.FileManager1` dbus interface (e.g. having both XFCE's Thunar and KDE's Dolphin installed) may/will result in one of those filemanagers being executed. In my case Thunar was consistently used, until a `ln -s /usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service $XDG_DATA_HOME/dbus-1/services/org.freedesktop.FileManager1.service`. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1285711#c47

So:
* If your default filemanager actively listens/responds to the `org.freedesktop.FileManager1` dbus interface, it works as expected
* If your default filemanager supports `org.freedesktop.FileManager1` but doesn't actively listen/respond to it, it depends
* If your default filemanager doesn't support `org.freedesktop.FileManager1` but other installed filemanager(s) do, it's still broken
* If your default filemanager doesn't support `org.freedesktop.FileManager1` and no other installed filemanager(s) do (or you overrule the service so nothings responds to it), it works as expected

Firefox 107.0.1 (64-bit), Slackware64-current, KDE Frameworks 5.100.0, XFCE 4.16, Thunar 4.16.11

[Koraciqid (koraciqid)]

Created attachment 9383414
same problem

Thanks from susinorse1970.