According to Specifications/mime-actions-spec, an entry in mimeapps.list is supposed to be treated as a semicolon-separated list of applications, sorted from most to least preferred. However, with current git HEAD (b961235b197647d6649ef3d48d7cc2cecafe3d47), xdg-open simply treats it as a filename and uses the $BROWSER fallback if xdg-mime returns a semicolon-separated list.
Created attachment 54838 [details] [review] Possible fix Here's a patch that should solve the problem... but since I can't remember what I did to make xdg-open the last time, it has only been tested in the sense that: 1. it worked for me when I wrote it in the generated xdg-open. 2. When I asked diff to compare the `git diff` output for both cases, the only lines that didn't match were ones I didn't touch. (so I'm guessing make did)
I stumbled over the same problem when trying to reproduce a bug filed at openSUSE's bugzilla (https://bugzilla.opensuse.org/show_bug.cgi?id=979265), i.e. the same problem exists when trying to open a folder with xdg-open (e.g. "xdg-open ." as in this specific openSUSE bugreport). I don't think patching xdg-open is the proper solution though. IMHO, "xdg-mime query default xxx" should not return the ';' (or the whole line actually, including all listed applications) in the first place, it doesn't when run inside a KDE session. To demonstrate the problem more clearly: Say, mimeapps.list contains this: [Default Applications] inode/directory=kde4-krusader.desktop; Inside a KDE session "xdg-mime query default inode/directory" returns "krusader.desktop". In IceWM e.g. (i.e. when the generic path is taken) it's "kde4-krusader.desktop;" instead, on which xdg-open chokes then. The problem is even more obvious if you add a second application to the default applications line, as explicitly mentioned in the specification (https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s04.html): [Default Applications] inode/directory=kde4-krusader.desktop;kde4-dolphin.desktop; Inside KDE, xdg-mime still returns "krusader.desktop", but the generic version returns the whole line, "kde4-krusader.desktop;kde4-dolphin.desktop;" Apparently the correct behavior would be to check the specified desktop files in the order specified and return only the first one that actually exists (this is how it behaves inside a KDE session). But it would help already if it would just strip everything after (and including) the first semicolon I suppose.
What version of xdg-utils are you using to test? Using the latest code, slightly newer than recent 1.1.1 release, I cannot reproduce your findings (marking fixed)
(In reply to Rex Dieter from comment #3) > What version of xdg-utils are you using to test? Sorry, I forgot to specify that. I used openSUSE's latest package from the devel repo, which contains a git snapshot from 20151219. The most recent entry in the changelog is this: 2015-12-19 Rex Dieter <rdieter@fedoraproject.org> * xdg-open: improve fallbacks, add open_generic (almost) everywhere (BR93442) I could try the latest git version too, but I don't see any change that should fix it since then... Please note that this only happens when the generic code path is taken though, i.e. you need to run it in IceWM e.g. (not KDE or GNOME).
I set env var: XDG_CURRENT_DESKTOP=X-Generic XDG_UTILS_DEBUG_LEVEL=2 prior to running xdg-utils tools, that should be sufficient for testing (as far as I can tell)
(In reply to Rex Dieter from comment #5) > I set env var: > > XDG_CURRENT_DESKTOP=X-Generic > XDG_UTILS_DEBUG_LEVEL=2 > > prior to running xdg-utils tools, that should be sufficient for testing (as > far as I can tell) Yes, should be. Still, the problem is not fixed here, also with latest git master: :~> XDG_CURRENT_DESKTOP=X-Generic :~> XDG_UTILS_DEBUG_LEVEL=2 :~> xdg-mime query default inode/directory Checking /home/wolfi/.config/mimeapps.list kde4-krusader.desktop;kde4-dolphin.desktop; When running "xdg-open .", it starts Firefox instead. /home/wolfi/.config/mimeapps.list looks like this: [Added Associations] inode/directory=kde4-krusader.desktop; [Default Applications] inode/directory=kde4-krusader.desktop;kde4-dolphin.desktop; Changing the last line (below "[Default Applications]") to just "inode/directory=kde4-krusader.desktop" (without a ';') makes it work as expected. But, the openSUSE maintainer is working on a fix, see https://bugzilla.opensuse.org/show_bug.cgi?id=979265
OK, seems my testing methodology was flawed, let's continue the investigation.
here's the patch I'm currently testing (with good results so far): diff --git a/scripts/xdg-mime.in b/scripts/xdg-mime.in index 63b8a82..c60f220 100644 --- a/scripts/xdg-mime.in +++ b/scripts/xdg-mime.in @@ -370,7 +370,7 @@ check_mimeapps_list() found=1 } } -' "$mimeapps_list") +' "$mimeapps_list" | cut -d ';' -f 1) if [ -n "$result" ]; then echo "$result" exit_success
https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=a5ec775d7631bf32760acc1c1b54a4905cfdec89 Should do it (I hope).
Created attachment 124299 [details] [review] fix desktop-file-to-binary This patch is required to make my next patch work properly
Created attachment 124300 [details] [review] xdg-mime only return existing desktop files This fixes xdg-mime in a "more correct way" rather then returning the first item it returns the first item in the list that exists. For an item to exist its desktop file and binary must both be found. Its been a long time since i've contributed patches so I don't remember how to so feel free to point me to the doco on that.
Created attachment 127887 [details] [review] This patch checks filenames with a - after checking the vendor prefix.
I'm going to re open this as the patches attached haven't been accepted and do a better job of this by only returning the result if the desktop file and binary actually exist on the system.
applied patches Thanks! (sorry for the delay) I'm still a little nervous about the behavior change, but I think it's for the best long-term.
Created attachment 134577 [details] [review] fix autotests Please apply my patch to fix tests.
latest patch applied, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.