[bug] Links with target=_blank and shell::open do not work from AppImage on Linux

[0rvar]

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

[a5huynh]

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()?;

[amrbashir]

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

[amrbashir]

I should also note that the above repro works fine on my KDE.

[a5huynh]

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-open & 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!

[amrbashir]

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?

[0rvar]

@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.

[amrbashir]

The two system had the same distro or different ones? in case they were different, which one had the issue?

[0rvar]

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.

[rsk700]

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.