Open Bug 1106916 Opened 7 years ago Updated 2 years ago

On Linux/BSD, the "open containing folder" in the downloads page does not respect XDG conventions for choosing which file manager to load


(Core :: Widget: Gtk, defect, P5)

33 Branch




(Reporter: sidnioulz, Unassigned)



(Whiteboard: tpi:-)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141115160330

Steps to reproduce:

(I am using ArchLinux + Xfce, latest stable Firefox)
1) Went to Downloads Page
2) Clicked "Open containing folder"

Actual results:

Nautilus was launched by Firefox, instead of my DE's default file manager Thunar. This occurs because Nautilus implements FileManager and Thunar doesn't, yet my DE has Thunar set up as the default file manager.

The XDG FileManager spec is used by Firefox to highlight a file in a folder, which is arguably a lesser factor to UX than being able to consistently use one's favourite file manager rather than another app the user may be unacquainted with.

Expected results:

Firefox should, until all major DEs have implemented the FileManager spec, respect the xdg-open logic for figuring out which file manager to launch. It should figure out which file manager must be launched and then only use the FileManager DBus API if the file manager implementing the corresponding DBus interface is the default file manager. I believe such an effort on behalf of Firefox is reasonable until this DBus interface gets adoption beyond a single unique file manager.
I can confirm this bug.  I have managed to trace it down to this file:
xpcom/io/nsLocalFileUnix.cpp (around line 1980)

  if (isDirectory) {
    if (giovfs) {
      return giovfs->ShowURIForInput(mPath);
    } else
      /* Fallback to GnomeVFS */
      return gnomevfs->ShowURIForInput(mPath);
  } else if (giovfs &&
             NS_SUCCEEDED(giovfs->OrgFreedesktopFileManager1ShowItems(mPath))) {
    return NS_OK;
  } else {
    nsCOMPtr<nsIFile> parentDir;
    nsAutoCString dirPath;
    if (NS_FAILED(GetParent(getter_AddRefs(parentDir)))) {
      return NS_ERROR_FAILURE;
    if (NS_FAILED(parentDir->GetNativePath(dirPath))) {
      return NS_ERROR_FAILURE;

    if (giovfs) {
      return giovfs->ShowURIForInput(dirPath);
    } else {
      return gnomevfs->ShowURIForInput(dirPath);

The downloaded item is not a directory, so it skips the first part and executes the second part using OrgFreedesktopFileManager1ShowItems.  Nautilus installs the service for the file manager spec, while Thunar/others do not.  I tested this by commenting out the second part:

  }/* else if (giovfs &&
             NS_SUCCEEDED(giovfs->OrgFreedesktopFileManager1ShowItems(mPath))) {
    return NS_OK;
  } */ else {

Uninstalling nautilus works because it removes the service, but I have several applications that depends on nautilus even though I don't use it as the file manager.  One possibility may be to provide a user setting that is tested within this second part to no use OrgFreedesktopFileManager1ShowItems if it is disabled.
I have just made the following changes and verify that it works:

xpcom/io/nsLocalFileUnix.cpp (top):

  #include "mozilla/Preferences.h"

xpcom/io/nsLocalFileUnix.cpp (~1994)

  } else if (giovfs && mozilla::Preferences::GetBool("", true) &&
             NS_SUCCEEDED(giovfs->OrgFreedesktopFileManager1ShowItems(mPath))) {
    return NS_OK;

Using this, when I do a "open containing folder", it uses Nautilus  by default (since is true by default).  I then go to "about:config" and add a new boolean value "" and set it to false.  Then "open containing folder" bypasses the OrgFreeDesktopFileManager1ShowItems and uses the code underneath it around line 1998 (gets directory of downloaded item and uses either giovfs or gnomevfs ShowURIForInput(dirPath).

This is probably not the correct place to put the config check though.  It would make more sense (to myself anyway) to put the check in the function itself something like this.  This option shouldn't disable DBUS entirely (it may be needed for other things), just disables it for opening files and directories.

toolkit/system/gnome/nsGIOService.cpp (about line 387):

  nsGIOService::OrgFreedesktopFileManager1ShowItems(const nsACString& aPath)
    return NS_ERROR_FAILURE;
  if(!mozilla::Preferences::GetBool("", true))
    return NS_ERROR_FAILURE;
Without making changes to the code, I can also put a file at ~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service by copying the file from /usr/share/dbus-1/services/ and then editing it.

If I use Exec=/usr/bin/Thunar --daemon, there is a long delay when first opening a containing folder and FF freezes up during that delay.  I learned from another report (266600) that I can also use Exec=/bin/false to prevent a delay.

  [D-BUS Service]
Karl, can you help or redirect to someone who can? :-)
Component: Untriaged → Widget: Gtk
Flags: needinfo?(karlt)
Product: Firefox → Core
Yes, this is bug in nautilus, but unfortunately Gecko is affected.  (See bug 417952 comment 17.)  I wonder whether there is a way to ensure that a dbus method call doesn't use an activatable service.  That would probably mean that nautilus would not usually be used, but I'm fine with that given it is the source of the problem.  Perhaps Nelson might have some ideas.
Blocks: 417952
Ever confirmed: true
Flags: needinfo?(karlt)
In my original report, I said Thunar didn't implement FileManager. Actually, they do, although I suspect very few apps use this approach. Brian, you might've hit a Thunar bug and I've made a report upstream with Xfce.

The interface Xfce uses is org.xfce.FileManager. I'm not sure how clients are expected to find the right file manager to talk to. The FDO ML discussion on the DBus interface is here:

To be honest if the spec does require that a single DE grabs org.freedesktop.FileManager, I'd rather Firefox relied on xdg-open which used to work for everyone pre-2013.
Looking at it like this, I don't really think it is a bug in Firefox.  All it does is:

* If org.freedesktop.FileManager1 ShowItems is available, use it
* Otherwise fall back to gio/xdg

It has no way to know if, in the case a user is not using Nautilus (or any other compliant file manager), that dbus is going to launch it from the services file anyway if the interface is not already up. A feature to turn off using org.freedesktop.FileManager1 wold be nice though.

I think the best solution is:

* Thunar should register the correct interface
* Nautilus should not install the service file /usr/share/dbus-1/services/org.freedesktop.FileManager1.service
* When the user logs in to their DE, it should launch the correct daemon that implements the interface.  Logging in to GNOME would launch "nautilus --no-default-window", logging in to XFCE would launch "thunar --daemon", and so on.
* All applications that use this feature should fall back to xdg.  If the DE doesn't use the interface, it will still allow launching a default file manager.  If the DE does use this interface but the application implementing the interface closed, crashed, or for whatever reason is not running, a fallback to xdg would still allow access without the interface.
Duplicate of this bug: 1165740
Please, can someone edit the platform of this bug? Symptoms are **not** limited to x86_64 Linux. 

Users of PC-BSD (based on FreeBSD) find Firefox wrongly opening something other than the user-preferred file manager. It's reasonable to assume that Firefox on FreeBSD is similarly bugged.
OS: Linux → All
Hardware: x86_64 → All
Summary: On Linux, the "open containing folder" in the downloads page does not respect XDG conventions for choosing which file manager to load → On Linux/BSD, the "open containing folder" in the downloads page does not respect XDG conventions for choosing which file manager to load
Isn't it possible make a special case for Thunar using

xdg-mime query default inode/directory

and if it is active use xdg-open?
Is this still reproducible? Is it a Firefox bug or not?
Whiteboard: tpi:?
Reproducible with Firefox 47.0.1 on TrueOS Desktop. I prefer Dolphin, Firefox uses GNOME Files.
Whiteboard: tpi:? → tpi:-
Reproducible with Firefox 49.0 on KDE on TrueOS Desktop. there's a workaround but please note, its effects are broad-ranging (extending beyond Firefox); the workaround will, for example, reduce the range of options that are available when a user of Dolphin calls up a contextual menu for a directory file (folder). 

(In reply to Brian Vanderburg from comment #7)

> … I think the best solution is:

> … * When the user logs in to their DE, it should launch the correct daemon
> that implements the interface.  Logging in to GNOME would launch "nautilus
> --no-default-window", logging in to XFCE would launch "thunar --daemon", 

That could be better than the current situation, although it does not cover use cases (such as mine) where the file manager is *not* the manager most commonly associated with a desktop environment. 

(When using Lumina: preferring Dolphin to Insight. When using MATE: preferring Dolphin to Caja. And so on.)
We came across this same issue when a user tried using a custom option we added to Nemo, our default. Firefox does not follow the default but opens Nautiles instead.

The workaround posted by Brian Vanderburg above still works.

We use Ubuntu 16.04 with the Cinnamon desktop and Firefox 60.0.2.
You need to log in before you can comment on or make changes to this bug.