xdg-utils issueshttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues2023-08-19T10:53:28Zhttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/84xdg-open does not spawn terminal for Terminal=true2023-08-19T10:53:28ZBugzilla Migration Userxdg-open does not spawn terminal for Terminal=true## Submitted by Thomas Gläßle
Assigned to **Portland Bugs**
**[Link to original bug (#92514)](https://bugs.freedesktop.org/show_bug.cgi?id=92514)**
## Description
Created attachment 118945
Ad hoc patch to launch terminal
xdg-open...## Submitted by Thomas Gläßle
Assigned to **Portland Bugs**
**[Link to original bug (#92514)](https://bugs.freedesktop.org/show_bug.cgi?id=92514)**
## Description
Created attachment 118945
Ad hoc patch to launch terminal
xdg-open does not spawn terminals for desktop files with `Terminal=true`.
For example consider the following configuration:
`~/.local/share/applications/ranger.desktop`:
[Desktop Entry]
Name=ranger
Type=Application
Terminal=true
Exec=ranger %F
`~/.local/share/applications/mimeapps.list`:
[Default Applications]
inode/directory=ranger.desktop
inode/mount-point=ranger.desktop
Then I expect ranger to be opened in a terminal upon running:
xdg-open /
What currently happens is:
(a) if running the command from a non-terminal context, xdg-open tries to execute ranger without terminal. This errors and xdg-open falls back to execute mimeopen which ignores mimeapps.list and only looks at defaults.list and therefore confusingly may use another default.
(b) if running the command within a terminal, ranger is opened in the current terminal. While this is fine, I think it would be fine as well to spawn a new terminal.
This applies to xdg-utils 1.1.1.
The attached patch spawns a new terminal asynchronously indiscriminately of case (a) versus case (b). It uses the TERMINAL environment variable, similar to what `mimeopen` does.
**Attachment 118945**, "Ad hoc patch to launch terminal":
[spawn_terminal.diff](/uploads/c0207e28d55645cd43a101301bb2ad99/spawn_terminal.diff)
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/82xdg-icon-resource does not support svg2021-07-05T09:04:54ZBugzilla Migration Userxdg-icon-resource does not support svg## Submitted by Rodrigo Silva
Assigned to **Portland Bugs**
**[Link to original bug (#91759)](https://bugs.freedesktop.org/show_bug.cgi?id=91759)**
## Description
Spec includes SVG http://standards.freedesktop.org/icon-theme-spec/...## Submitted by Rodrigo Silva
Assigned to **Portland Bugs**
**[Link to original bug (#91759)](https://bugs.freedesktop.org/show_bug.cgi?id=91759)**
## Description
Spec includes SVG http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html , but xdg-icon-resource does not support them
Attempting to install an SVG icon gives:
xdg-icon-resource: icon file to install must be a *.png or *.xpm file
Try 'xdg-icon-resource --help' for more information.
This is perhaps a duplicate of bug #7837 , and it was reported in Ubuntu's Launchpad https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/790449
Also, for scalable icons like SVG the --size argument should be optional (or not allowed at all)
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/151URL handler and xdg-mime not working when Exec line contains quoted path2023-12-21T05:22:59ZJonathan HaylettURL handler and xdg-mime not working when Exec line contains quoted pathWhen the command file path in the `Exec` field of a desktop file is wrapped in double quotes, xdg-mime and the URL handling seem to be unable to deal with it.
E.g.
```
[Desktop Entry]
Name=Slippi Launcher
Comment=Slippi Desktop App for ...When the command file path in the `Exec` field of a desktop file is wrapped in double quotes, xdg-mime and the URL handling seem to be unable to deal with it.
E.g.
```
[Desktop Entry]
Name=Slippi Launcher
Comment=Slippi Desktop App for browsing and playing replays.
Exec="/home/haystack/source/Slippi-Launcher-1.4.5-x86_64.AppImage" %U
Terminal=false
Type=Application
Icon=appimagekit-slippi-desktop-app
StartupWMClass=Slippi Launcher
X-AppImage-Version=1.4.5
MimeType=x-scheme-handler/slippi;
Categories=Development;
X-AppImage-BuildId=1K1bOeuJzPhoG9WcseHboZyGhZK
X-Desktop-File-Install-Version=0.24
X-AppImage-Comment=Generated by /tmp/.mount_SlippipSpjHL/AppRun
TryExec=/home/haystack/source/Slippi-Launcher-1.4.5-x86_64.AppImage
```
```
❯ xdg-settings set default-url-scheme-handler slippi appimagekit-slippi-desktop-app.desktop
which: no Slippi-Launcher-1.4.5-x86_64.AppImage" in (./"/home/haystack/source)
```
[The desktop entry spec](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables) seems to say that quoting the path should be fine. Based on this it seems that xdg-utils is not correctly implementing the desktop file specification. Desktop files with a quoted exec path usually work fine.
[electron-builder](https://github.com/electron-userland/electron-builder) also seems to (quite reasonably) create desktop files with a quoted file path, but then they are broken with xdg-utils (URL handling won't work, nor will xdg-mime). If there are spaces in the file path or any other special character that needs escaping, then backslashes would have to be inserted which is much more inconvenient than quoting the whole path, which works pretty much everywhere else in GNU/Linux.
I believe this is something that should be fixed on xdg-utils' end, not in electron-builder or any other program that quotes the executable paths in desktop entries.
See also:
https://github.com/project-slippi/slippi-desktop-app/issues/24
https://github.com/electron-userland/electron-builder/issues/2759https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177Attaching files with mailto:?attach=... parameter is considered dangerous2024-03-17T22:18:44ZJens MuellerAttaching files with mailto:?attach=... parameter is considered dangerousIn `run_thunderbird()`, xdg-email greps for a proprietary `attach` parameter:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-email.in#L51
This allows arbitrary websites with mailto links to add local files on dis...In `run_thunderbird()`, xdg-email greps for a proprietary `attach` parameter:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-email.in#L51
This allows arbitrary websites with mailto links to add local files on disk into the Thunderbird's email composition dialog and should be removed: https://twitter.com/i/status/1295357952480751616
After Thunderbird removed this functionality years ago, I think xdg-email somewhat re-introduced it.
Original bug report for Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=1613425https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/240allow forcing use of portal with env var2023-12-05T19:45:24ZMichael Leuchtenburgallow forcing use of portal with env varIn some environments, the standard method of opening a program may not work due to e.g. lack of availability of the binaries or presence of conflicting libraries in LD_LIBRARY_PATH. One case of this is currently handled for Flatpak, but ...In some environments, the standard method of opening a program may not work due to e.g. lack of availability of the binaries or presence of conflicting libraries in LD_LIBRARY_PATH. One case of this is currently handled for Flatpak, but others are not. To give users an easy workaround when using portals is desirable, it would be useful to allow overriding the open method choice via an environment variable.
Currently, this could only be done by creating a file, $XDG_RUNTIME_DIR/flatpak-info. An env var such as XDG_OVERRIDE_DE (for all utils) or XDG_OPEN_OVERRIDE_DE would make this simpler. I propose solving it this way rather than just adding an override to force using the portal because it would also cover other cases where a user wants different behavior.
An example of this being done by a packager via a patch adding an env var can be seen in https://github.com/NixOS/nixpkgs/pull/197118https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/180Missing parameter in set_url_scheme_handler_gnome3?2021-05-04T01:47:55ZargenosMissing parameter in set_url_scheme_handler_gnome3?I've been down a small rabbit hole, trying to figure out why [some electron apps set themselves as the default `text/html` application](https://github.com/electron/electron/issues/20382#issuecomment-537627348).
Based on what I've learned...I've been down a small rabbit hole, trying to figure out why [some electron apps set themselves as the default `text/html` application](https://github.com/electron/electron/issues/20382#issuecomment-537627348).
Based on what I've learned, it seems that they're using `xdg-utils` to set up custom URL protocols.
Could it be that the issue is that on this [line](https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L691), it passes no 2nd param the first time, which defaults to `text/html`? See [this](https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L134) too.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/107xdg-mime does not handle whitespace in .desktop file names correctly2023-10-01T12:39:18ZBugzilla Migration Userxdg-mime does not handle whitespace in .desktop file names correctly## Submitted by Vladimir Panteleev
Assigned to **Portland Bugs**
**[Link to original bug (#101039)](https://bugs.freedesktop.org/show_bug.cgi?id=101039)**
## Description
On my system, running:
$ xdg-open http://google.com
Prints...## Submitted by Vladimir Panteleev
Assigned to **Portland Bugs**
**[Link to original bug (#101039)](https://bugs.freedesktop.org/show_bug.cgi?id=101039)**
## Description
On my system, running:
$ xdg-open http://google.com
Prints this to stderr:
/usr/sbin/xdg-mime: line 323: [: too many arguments
/usr/sbin/xdg-mime: line 325: [: too many arguments
xdg-mime at line 323 looks like this:
if [ -r $dir/applications/$vendor/$app ]; then
file_path=$dir/applications/$vendor/$app
elif [ -r $dir/applnk/$vendor/$app ]; then
file_path=$dir/applnk/$vendor/$app
fi
It looks like xdg-mime does not properly quote variables before expansion, which makes them subject to globbing and word splitting.
The particular file that causes xdg-mime to misbehave is:
/home/vladimir/.local/share/applications/userapp-Firefox Developer Edition-ZN8AEY.desktop
I'm not sure what created it, but it does have spaces in the file name.
Regardless of whether spaces are allowed in such file names, not quoting variables that are not intended to be expanded is a bug.
I strongly recommend linting shell scripts with ShellCheck (http://www.shellcheck.net/) to prevent bugs like this one.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/81xdg-desktop-menu: Drop obsolete GNOME support2023-08-07T08:31:25ZBugzilla Migration Userxdg-desktop-menu: Drop obsolete GNOME support## Submitted by Johannes Löthberg
Assigned to **Portland Bugs**
**[Link to original bug (#90775)](https://bugs.freedesktop.org/show_bug.cgi?id=90775)**
## Description
This commit drops the obsolete support for the GNOME-specific d...## Submitted by Johannes Löthberg
Assigned to **Portland Bugs**
**[Link to original bug (#90775)](https://bugs.freedesktop.org/show_bug.cgi?id=90775)**
## Description
This commit drops the obsolete support for the GNOME-specific directory
for .desktop files, since it has not been needed since GNOME 2.10, and
since it forces the creation of ~/.gnome whether you want it or not.Simon LeesSimon Leeshttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/182xdg-open fails to open URL when .desktop file path contains spaces2023-09-28T00:04:08ZAlexandre Abriouxxdg-open fails to open URL when .desktop file path contains spacesHi!
My `.desktop` file resides here and contains spaces:
`~/.local/share/applications/userapp-Firefox Developer Edition-UV383Z.desktop`
While using `xdg-open` I encounter the following error:
```
$ BROWSER=firefox ./xdg-open https://...Hi!
My `.desktop` file resides here and contains spaces:
`~/.local/share/applications/userapp-Firefox Developer Edition-UV383Z.desktop`
While using `xdg-open` I encounter the following error:
```
$ BROWSER=firefox ./xdg-open https://google.com
./xdg-open: 1: ./xdg-open: xdg-mime: not found
./xdg-open: 881: ./xdg-open: firefox: not found
./xdg-open: 881: ./xdg-open: firefox: not found
xdg-open: no method available for opening 'https://google.com'
```
I will post a merge request following the opening of this issue to try and fix it.
Thanks!https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/12xdg-mime with kde 5 cannot find kde-config2023-11-14T23:57:37ZClarence "Sparr" Risherxdg-mime with kde 5 cannot find kde-confighttps://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-mime.in#L136-142
```
$ XDG_UTILS_DEBUG_LEVEL=5 xdg-mime default google-chrome.desktop text/html
make_default_kde: No kde runtime detected
make_default_generic google-...https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-mime.in#L136-142
```
$ XDG_UTILS_DEBUG_LEVEL=5 xdg-mime default google-chrome.desktop text/html
make_default_kde: No kde runtime detected
make_default_generic google-chrome.desktop text/html
Updating /home/sparr/.config/mimeapps.list
```
I believe that for KDE_SESSION_VERSION==5 then this should be using `kf5-config` to find the config path.
I am unclear on whether `profilerc` is still a valid configuration file name in that case.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/232xdg-email: Keep or throw away --attach ?2023-10-14T12:33:17ZSlatianxdg-email: Keep or throw away --attach ?This issue related to #177 and !58 but is not about the CVE.
`xdg-email --attach` is useful. period. but …
… the underlying implementation is Thunderbird specific (and broken) and supporting other clients would add a lot of complexity ...This issue related to #177 and !58 but is not about the CVE.
`xdg-email --attach` is useful. period. but …
… the underlying implementation is Thunderbird specific (and broken) and supporting other clients would add a lot of complexity as there is no standard, de-facto standard or even semi-standard way of calling a mail-client in a way that attaches a file.
The current implementation has the following problems:
* The way the filepath is passed is an exploitable footgun.
* `'`, `,` and probably some other characters are not usable as filenames, solvable by switching to `file:` URIs.
* Thunderbird and Icedove have well-known desktop-file names, other mail-clients aren't that lucky,detecting them will probably turn into a mess
* How do I know that the configured mail-client supports the `--attach` option (if the answer is testing if its TB or ID then why use `xdg-email` at all)
* `xdg-email` is a very bad `xdg-open` remake without a lot of the improvements that went into `xdg-open`
* …
## Throwing away
Throwing this option away will definitly break some workflows. xdg-email would turn into something that assembles a `mailto:` address that gets handed over to xdg-open and done.
## Keeping it
Keeping it would mean someone has to fix …
* the issues directly related to the `run_thunderbird` function.
* communicating if --attach is possible (i.e. with a `--can-attach` option)
* the issue on how to deal with other mail-clients
* let xdg-open and xdg-mime do their job in order to reduce the complexity in xdg-email
Problem here is that someone has to do that and I know that I won't have enough time for this in the near future.
## In any way
* document the intended use of xdg-email
* move the interpretation of the `MAILER` Variable to xdg-open, it is the script that handles mail URIs from all over.
## What to do?
To be honest: I really don't know … both sides have pros and cons I'm levng this here for discussion.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/215xdg-desktop-menu.xml does not validate2023-02-21T14:01:58Zkiki Shaoxdg-desktop-menu.xml does not validatewhen I make the file, the following bug is reported, How can I fix it?
(cd html;/opt/homebrew/bin/xmlto html-nochunks ../desc/xdg-desktop-menu.xml)
xmlto: /Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml does not vali...when I make the file, the following bug is reported, How can I fix it?
(cd html;/opt/homebrew/bin/xmlto html-nochunks ../desc/xdg-desktop-menu.xml)
xmlto: /Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml does not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd
/Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml:6: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
]>
^
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd
warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
validity error : Could not load the external subset "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
Document /Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml does not validate
make[1]: *** [html/xdg-desktop-menu.html] Error 13
make: *** [scripts] Error 2https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/207convert xdg-open usage of egrep to grep -E2022-09-04T16:36:51ZAndreas Stiegerconvert xdg-open usage of egrep to grep -E`scripts/xdg-open.in` calls `egrep`, should be converted to `grep -E` to avoid raising warnings with GNU grep 3.8`scripts/xdg-open.in` calls `egrep`, should be converted to `grep -E` to avoid raising warnings with GNU grep 3.8https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/206xdg-settings set default-url-scheme-handler additionally sets text/html mime ...2023-08-09T02:17:03ZJoe Mouxdg-settings set default-url-scheme-handler additionally sets text/html mime type handler on Gnome 3In addition to associating a scheme handler, `xdg-settings set default-url-scheme-handler scheme app.desktop` will also associate `app.desktop` as the default handler for `text/html`; this only appears to affect Gnome 3.
This appears to...In addition to associating a scheme handler, `xdg-settings set default-url-scheme-handler scheme app.desktop` will also associate `app.desktop` as the default handler for `text/html`; this only appears to affect Gnome 3.
This appears to be a bug in `set_url_scheme_handler_gnome3`. It includes the line `set_browser_mime "$2" || return` which in the single-argument form defaults to associating app.desktop (`$2`) with `text/html`; this appears to be an accidental copy-and-paste from `set_browser_gnome3`.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/204/usr/bin/xdg-mime: line 323: [: too many arguments2023-10-11T20:30:03ZMichael Catanzaro/usr/bin/xdg-mime: line 323: [: too many argumentsUsing xdg-utils-1.1.3-11.fc36:
```
$ xdg-mime query default 'text/plain'
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/x...Using xdg-utils-1.1.3-11.fc36:
```
$ xdg-mime query default 'text/plain'
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
org.gnome.TextEditor.desktop
```
No clue why it doesn't like this code:
```
if [ -r $dir/applications/$vendor/$app ]; then
file_path=$dir/applications/$vendor/$app
elif [ -r $dir/applnk/$vendor/$app ]; then
file_path=$dir/applnk/$vendor/$app
fi
```https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/168xdg-settings: adapt to KDE changes2020-12-03T21:36:09ZMéven Carxdg-settings: adapt to KDE changesIn https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L214:
The script checks with text/html but Kde plasma now stores the default browser as the associated app to "x-scheme-handler/http".
In https://gi...In https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L214:
The script checks with text/html but Kde plasma now stores the default browser as the associated app to "x-scheme-handler/http".
In https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L239
This function is wrong nowadays, plasma uses the application associated with "x-scheme-handler/http" as default browser if no BrowserApplication is set in kconfigglobals.
Basically, KDE plasma is now closer xdg specification.
https://phabricator.kde.org/D17371https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/166xdg-open dose not search correctly in directories with spaces in the name2022-06-27T19:45:36ZAndrea Tarocchixdg-open dose not search correctly in directories with spaces in the nameThe problem is in `search_desktop_file()` function more precisely at https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-open.in#L331
as an example to reproduce the issue try the snippet below:
```
reproducer()
{
loc...The problem is in `search_desktop_file()` function more precisely at https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-open.in#L331
as an example to reproduce the issue try the snippet below:
```
reproducer()
{
local dir="$1"
for d in "$dir"/*/; do
echo "$d"
done
}
reproducer /home/valdar/.local/share/applications/Space\ Name/
```
you will see that the output is:
```
/home/valdar/.local/share/applications/Space
Name//*/
```
instead of:
```
/home/valdar/.local/share/applications/Space Name//*/
```
This is not only harmful because some directories are not searched, but also because it can lead to infinite loops and escape the search to directories outside the paths configured in `XDG_DATA_DIRS`. As an example think about running `xdg-open` from a directory with this structure:
```
games
|_my games
```
and one of the directories in your `XDG_DATA_DIRS` contains a directory named `not games`. You end up in an infinite loop.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/161xdg-open only substitutes field codes that are surrounded by spaces2023-11-16T00:30:07ZSebastiaan Lokhorstxdg-open only substitutes field codes that are surrounded by spaces`xdg-open` only substitutes field codes such as `%f` if they are separate arguments, i.e. if they are surrounded by spaces.
This works:
```
Exec=foo --bar %f
```
This doesn't work:
```
Exec=foo --bar=%f
```
The [Desktop Entry Specific...`xdg-open` only substitutes field codes such as `%f` if they are separate arguments, i.e. if they are surrounded by spaces.
This works:
```
Exec=foo --bar %f
```
This doesn't work:
```
Exec=foo --bar=%f
```
The [Desktop Entry Specification](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables) does not seem to mention that field codes have to be surrounded by spaces. Other openers such as `gio open` do not have this limitation.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/159xdg-mime --all query default2023-08-09T08:04:33Z積丹尼 Dan Jacobsonxdg-mime --all query defaultSure we can do one by one
```
$ xdg-mime query default image/png
wine-extension-png.desktop
$ xdg-mime query default application/zip
...
```
but why not allow us to see them all
`$ xdg-mime query default ALL`
or
`$ xdg-mime --all quer...Sure we can do one by one
```
$ xdg-mime query default image/png
wine-extension-png.desktop
$ xdg-mime query default application/zip
...
```
but why not allow us to see them all
`$ xdg-mime query default ALL`
or
`$ xdg-mime --all query default`https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/150xdg-open can not open urls in LXDE2023-08-09T08:21:31ZWilliam Smithxdg-open can not open urls in LXDEAfter upgrade from Debian Stretch (xdg-utils_1.1.1) to Buster (xdg-utils_1.1.3) I was unable to open any mime url with xdg-open. All was opened by pcmanfm and it coudnt't handle it.
This answer solved all problems: [https://unix.stackexc...After upgrade from Debian Stretch (xdg-utils_1.1.1) to Buster (xdg-utils_1.1.3) I was unable to open any mime url with xdg-open. All was opened by pcmanfm and it coudnt't handle it.
This answer solved all problems: [https://unix.stackexchange.com/questions/450200/xdg-open-on-debian-9-fails-to-open-browser](https://unix.stackexchange.com/questions/450200/xdg-open-on-debian-9-fails-to-open-browser) by editing the /usr/bin/xdg-open
If this is a bug please be aware it.