Bug#874003: Nautilus does not launch applications

[Simon McVittie]

Control: retitle -1 setting a handler for x-scheme-handler/file pseudo-MIME-type results in GLib applications sending all files to it
Control: clone -1 -2 -3
Control: reassign -1 libglib2.0-0 2.53.6-1
Control: affects -1 nautilus
Control: block -1 by -2
Control: reassign -2 exo-utils 0.6.2-5
Control: forwarded -2 https://bugzilla.xfce.org/show_bug.cgi?id=7257
Control: tags -2 + fixed-upstream
Control: close -2 0.10.2-4
Control: affects -2 nautilus
Control: block -1 by -3
Control: reassign -3 enlightenment 0.22.4-1
Control: affects -3 nautilus

On Fri, 21 Dec 2018 at 18:41:06 -0600, Drew Vogel wrote:
> I tried both of the fixes mentioned in messages #70 and #75. They both worked
> for me. Thanks everyone!

Hi,
If possible please quote a bit more context when sending emails to bug
reports, and in particular keep the subject line intact: maintainers
will often get these emails completely out of context, and have to look
up the bug number on the web interface to even find out which package
you're talking about, never mind which bug.

The context here is:

* Double-clicking on a file, or right-click and "Open with xxxx", just
  reopened Nautilus instead
* Diagnosis: nautilus ran "gio open" which ran exo-open (from Xfce's
  exo-utils) which just re-ran Nautilus
* Workaround (from message #60): remove exo-utils
* Workaround (from message #70): move
  /usr/share/applications/exo-file-manager.desktop out of the search path
* Workaround (from message #75): remove
  x-scheme-handler/file=exo-file-manager.desktop from
  ~/.local/share/applications/mimeapps.list

Do all the people suffering from this bug have x-scheme-handler/file
in their ~/.local/share/applications/mimeapps.list?

Having exo-open as a handler for the pseudo-MIME-type
x-scheme-handler/file seems to have been an upstream bug
<https://bugzilla.xfce.org/show_bug.cgi?id=7257> which was initially
fixed with a Debian patch in 0.10.2-4, and later fixed upstream in
0.10.5. GLib treats x-scheme-handler/file as being a handler for *all*
file: URLs, no matter what they point to (I don't know whether/which
non-GLib implementations of freedesktop.org MIME handlers do the
same, but Nautilus and gio(1) both use GLib). This is appropriate for
some URL scheme pseudo-MIME-types like x-scheme-handler/mailto and
x-scheme-handler/rtsp, but not for x-scheme-handler/file.

The solution to XFCE upstream bug #7257 was to set exo-open as a handler
for the pseudo-MIME-type inode/directory instead (which causes it to
handle directories, but not regular files), putting it in the same
category as Nautilus, Thunar, pcmanfm and enlightenment_filemanager,
among others. However, this change wouldn't remove any existing
x-scheme-handler/file entries from mimeapps.list. Entries in
~/.local/share/applications/mimeapps.list also don't respect OnlyShowIn
(I think this is deliberate, because mimeapps.list can be used to add
user-specific associations that overrule applications' defaults).

I don't think it makes much sense to set an application as a handler for
all file: URLs by setting an x-scheme-handler/file handler, except in
the special case of trying to prevent files from opening in any other
handler (which gdm3 does by setting "mime-dummy-handler.desktop" as the
handler for various URL schemes, including file:, while in the "greeter"
session that provides the gdm login prompt).

While researching this in codesearch.debian.net I found that e17
(Enlightenment) still sets the user-preferred file manager by setting
it as an x-scheme-handler/file handler. e17 maintainers, please
don't do this: the interoperable freedesktop.org pseudo-MIME-type
for a general-purpose file manager like Nautilus, Thunar, Dolphin
or (presumably) enlightenment_filemanager is inode/directory, and
enlightenment_filemanager's desktop file already announces it as an
inode/directory handler. I was tempted to set the cloned bugs in exo-utils
(already fixed) and enlightenment (not fixed) as release-critical,
but for now I've left them set to important.

In principle GLib could special-case x-scheme-handler/file to be ignored,
but I don't think that's a good idea, because it would be a special case
for something that should never happen in normal desktop sessions anyway,
and it would mean that the locked-down gdm3 session would have no general
way to prevent files from being opened.

I'm also not sure whether it's really appropriate for exo-utils to be
registering its programs as MIME type handlers, and then dispatching
to a real MIME type handler from there according to XFCE-specific
configuration. It would seem more appropriate for XFCE to set the
real file manager application (e.g. Thunar) as the handler for the
inode/directory pseudo-MIME-type, directly, and similarly set the real
web browser (e.g. Firefox) as the handler for x-scheme-handler/http
and the real mail client as the handler for x-scheme-handler/mailto,
migrating the XFCE-specific configuration into the MIME list on first-run
after upgrade. That's what GNOME does, and I think also what KDE does?

    smcv