Fix in my case
- If
xdg-open
works fine from console butobsidian
still opens wrong browser, and you are using Snap you can use following hack to fix it:
- ensure that
~/bin
is on yourPATH
(echo $PATH
) - or use different location - create
~/bin/xdg-open
with following content:
#!/bin/bash
# fix for obsidian opening URLs in wrong browser
if [[ $SNAP_INSTANCE_NAME == "obsidian" && $1 =~ ^(https?://) ]]; then
unset XDG_DATA_HOME
unset XDG_CONFIG_HOME
fi
exec /usr/bin/xdg-open "$@"
- save the script
- make it executable:
chmod +x ~/bin/xdg-open
Now obsidian should run correct browser.
DISCLAIMER: There may be some unexpected downsides coming from this solution. It wasn’t tested very deeply. USE AT YOUR OWN RISK. Maybe there is better solution but this piece of “duct tape” solved my case
- If xdg-open run from the console opens wrong browser, use the solution suggested by others (to fix your system level configuration):
xdg-mime default google-chrome.desktop x-scheme-handler/http
xdg-mime default google-chrome.desktop x-scheme-handler/https
Why this (1) works?
From my quick investigation:
- strace shows that obsidian searches for xdg-open on PATH and invokes the first one found
- xdg-open executed from console normally opens the right browser
- xdg-open executed by obsidian opens wrong browser
After comparing the env
output I’ve spotted that Snap crates it’s own XDG “environment”, where especially the two variables cause trouble (although there may be more…):
XDG_DATA_HOME=/home/youruser/snap/obsidian/24/.local/share
XDG_CONFIG_HOME=/home/youruser/snap/obsidian/24/.config
The XDG_CONFIG_HOME
messes with configuration (which browser should open) and the XDG_DATA_HOME
messes with browser (at least chrome does respect this variable - Chromium Docs - User Data Directory - and due to this it starts new process with empty profile).
So removing those two from environment before invoking real xdg-open
falls back to your default config.