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