tauri
tauri copied to clipboard
[bug] Links with target=_blank and shell::open do not work from AppImage on Linux
Describe the bug
When running a Tauri app on Linux using an AppImage, target=_blank links do not work, and shell::open does not work either.
Reproduction
Minimal reproduction repo: https://github.com/0rvar/tauri-appimage-repro
Create a link with target=_blank, or use shell::open with an URL. Then run the tauri app as an AppImage. It will silently fail to open the link when clicked, and silently fail to open the browser with the URL from shell::open.
Expected behavior
The browser should open with the URL
Platform and versions
Linux, AppImage. See reproduction repo above
Stack trace
No response
Additional context
No response
For others facing this same issue, I was facing this same problem and found a workaround, at least for the shell::open
portion.
I ended up calling xdg-open
directly with tauri::api::process::Command
and had to set the current_dir
to the folder that the AppImage is in. By default the current dir for an AppImage is some tmp folder where the AppImage has been unpacked and prevents the open command from running correctly.
Here's roughly what I did:
let binary_path = tauri::api::process::current_binary(&Env::default())?;
let parent = binary_path.parent().unwrap().to_path_buf();
tauri::api::process::Command::new("xdg-open")
.args(vec!["https://tauri.app".into()])
.current_dir(parent)
.output()?;
Please provide a full information of tauri info
and what desktop manager are you using, also check if any of the following tools are installed or not, xdg-open
, gio
, gnome-open
, kde-open
, wslview
I should also note that the above repro works fine on my KDE.
Hey @amrbashir, this is on the latest Ubuntu. I use this box for testing linux/Ubuntu so it is not modified outside of the base install.
From uname -a
Linux ubuntu-test 5.19.0-35-generic #36~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 17 15:17:25 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
xdg-ope
n & gio
are installed, gnome-open
, kde-open
, & wslview
are not.
> xdg-open --version
xdg-open 1.1.3
> gio version
2.72.4
Here are the details from cargo tauri info
using the reproducible Github repo in the op.
Environment
› OS: Ubuntu 22.04 X64
› Node.js: 18.14.2
› npm: 9.5.0
› pnpm: Not installed!
› yarn: Not installed!
› rustup: 1.25.2
› rustc: 1.67.1
› cargo: 1.67.1
› Rust toolchain: stable-x86_64-unknown-linux-gnu
Packages
WARNING: no lock files found, defaulting to npm
› @tauri-apps/cli [NPM]: 1.2.3
› @tauri-apps/api [NPM]: Not installed!
› tauri [RUST]: 1.2.4,
› tauri-build [RUST]: 1.2.1,
› tao [RUST]: 0.15.8,
› wry [RUST]: 0.23.4,
App
› build-type: bundle
› CSP: unset
› distDir: ../src
› devPath: ../src
package.json not found
App directory structure
├─ .vscode
├─ .git
├─ src
└─ src-tauri
Hope that helps track it down!
The thing is you say that std::process::Command
with xdg-open
works fine but shell::open
doesn't even though it uses open-rs
crate and that one actually just calls std::process::Command
with xdg-open
and I am not sure why you are facing this issue tbh
Could you guys try using open-rs
crate directly and see if it works?
@amrbashir It's very strange. This issue was 100% reproducible on another machine, but with my new Linux machine the reproduction repo does not showcase the issue.
The two system had the same distro or different ones? in case they were different, which one had the issue?
Exact same distribution (Ubuntu 22 LTS x64), exact same output from lsb_release -a
and uname -a
. Both fully up to date on packages. I've saved the output of printenv on that other machine, will compare against the output of my new machine and see if there's anything suspicious there.
I was testing my app, and faced similar problems with shell.open(...)
, I'm using it to open file paths and urls:
ubuntu 22 - open url doesn't work, open file path works fedora 38 - open works, but blocks tauri, while browser opened by shell.open is open, app can't communicate with backend, when browser closed all queued commands is processed, opening file path opens it in browser
win10, win11, ubuntu20 - open works as expected
I'm using tauri v1.3.0, AppImage build on ubuntu 20
After some exploring I've settled on using https://crates.io/crates/open directly:
pub fn open_path(path: String) {
// `open` required to run in separate thread, to avoid blocking on some
// platforms (eg Fedora38 blocks)
std::thread::spawn(|| {
for mut cmd in open::commands(path) {
// required to set path to good one to use `open` on Ubuntu 22
// (otherwise can be permission error)
cmd.current_dir(std::env::temp_dir());
if cmd.status().is_ok() {
break;
};
}
});
}
btw https://crates.io/crates/open docs do say:
Beware that on some platforms and circumstances, the launcher may block. In this case, please use the commands() or with_command() accordingly to spawn() it without blocking.