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

Status: NEW

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

Description

[Steve Dodier]

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.

http://www.freedesktop.org/wiki/Specifications/file-manager-interface/


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.

Comment 1

[Brian Vanderburg]

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.

Comment 2

[Brian Vanderburg]

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("browser.open.dbus.enable", true) &&
             NS_SUCCEEDED(giovfs->OrgFreedesktopFileManager1ShowItems(mPath))) {
    return NS_OK;
  }

Using this, when I do a "open containing folder", it uses Nautilus  by default (since browser.open.dbus.enable is true by default).  I then go to "about:config" and add a new boolean value "browser.open.dbus.enable" 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):

  NS_IMETHODIMP
  nsGIOService::OrgFreedesktopFileManager1ShowItems(const nsACString& aPath)
  {
  #ifndef MOZ_ENABLE_DBUS
    return NS_ERROR_FAILURE;
  #else
  if(!mozilla::Preferences::GetBool("browser.open.dbus.enable", true))
  {
    return NS_ERROR_FAILURE;
  }

Comment 3

[Brian Vanderburg]

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]
  Name=org.freedesktop.FileManager1
  Exec=/bin/false

Comment 4

[:Gijs (he/him)]

Karl, can you help or redirect to someone who can? :-)

Comment 5

[Karl Tomlinson (:karlt)]

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.

Comment 6

[Steve Dodier]

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: http://lists.freedesktop.org/archives/xdg/2011-May/011949.html

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.

Comment 7

[Brian Vanderburg]

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.

Comment 9

[Graham Perrin]

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.

Comment 10

[Alan]

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?

Comment 11

[Tracy Walker [:tracy]]

Is this still reproducible? Is it a Firefox bug or not?

Comment 12

[Graham Perrin]

Reproducible with Firefox 47.0.1 on TrueOS Desktop. I prefer Dolphin, Firefox uses GNOME Files.

Comment 13

[Graham Perrin]

Reproducible with Firefox 49.0 on KDE on TrueOS Desktop. 

https://forums.pcbsd.org/thread-21064.html 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.)

Comment 14

[Machiel]

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.

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1552613

Comment 16

[Pierre Ossman]

This got a bit more relevant now that Firefox downloads stuff directly without asking the user what to do with the file.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

We try to use the FileManager1 interface which should respect the system default. Is that not working? If not, how not?

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Oh, I see that per comment 1 Nautilus implements that but some other file managers don't? If so, maybe they should?

Comment 19

[Pierre Ossman]

Unfortunately, it seems to be more complex than that. When I'm using Firefox, it opens the Xfce file manager even though I'm on a GNOME desktop, and it should be opening Nautilus.

I reported this to GNOME as well, but the response wasn't great:

https://gitlab.gnome.org/GNOME/nautilus/-/issues/1902

Comment 20

[Pamela Archie]

Attachment: same problem

Thanks from coatellidad1974.