In LXDE if xdg-open is invoked with encoded file:// URL, PCManFM reports "no such file". It happens because xdg-open filters out 'file://' prefix on line 672: local file="$(echo "$1" | sed 's%^file://%%')" PCManFM recieves encoded URL without prefix, so it tries to open gibberish path without interpreting URL encoding. Example: xdg-open file:///tmp/media/%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0/ pcmanfm should recieve either 'file:///tmp/media/%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0/' or '/tmp/media/работа/' But it recieves '/tmp/media/%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0/' which is gibberish. 'file://' prefix should be passed through to PCManFM
I'm pretty sure file:// isn't a valid URL
ah, nevermind. I see the point you're making, and I think I agree.
Created attachment 101692 [details] [review] Fix for #63153 by passing the whole URL to pcmanfm The strategy of this patch is to avoid stripping file:// from the URL. The patch is based off the git version of xdg-utils, commit 869b22b7. I tested it on ArchLinux with some applications like clementine and calibre.
Created attachment 101693 [details] [review] Fix for #63153 by urldecoding Alternative patch: this takes the code already used in open_generic() to strip the file:// off the URL and then urldecode the rest of the string. The patch is based off the git version of xdg-utils, commit 869b22b7. I tested it on ArchLinux with some applications like clementine and calibre.
Created attachment 101704 [details] [review] Followup of 0001-xdg-open-fixes-63153-keeping-the-path-as-URL.patch With the previous patch file:// URLs with relative paths are expanded in the wrong way. This patch fixes it and must be applied after 0001-xdg-open-fixes-63153-keeping-the-path-as-URL.patch File URLs are described in RFC 1738, section 3.10 but it's not clear if relative paths are possible or not. xdg-open assumes it is possible so the new patch appends the current working directory between file:// and the rest in order to make it an absolute path. That's just the same old behavior applied to a file:// URL
I opted for the simpler initial version you supplied, 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.