Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
0rvar opened this issue Jan 30, 2023 · 10 comments
Labels
platform: Linux priority: 2 medium status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@0rvar
Copy link
Contributor

0rvar commented Jan 30, 2023

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

@0rvar 0rvar added status: needs triage This issue needs to triage, applied to new issues type: bug labels Jan 30, 2023
@a5huynh
Copy link

a5huynh commented Mar 3, 2023

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
Copy link
Member

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
Copy link
Member

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

@a5huynh
Copy link

a5huynh commented Mar 16, 2023

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
Copy link
Member

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
Copy link
Contributor Author

0rvar commented Apr 18, 2023

@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
Copy link
Member

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

@0rvar
Copy link
Contributor Author

0rvar commented Apr 23, 2023

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
Copy link

rsk700 commented May 22, 2023

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.

@fr-an-k
Copy link

fr-an-k commented Oct 13, 2024

I just created a Tauri 2 React app in WSL2 and ran the desktop version without issue, except this one.
The links in the example don't open unless I remove the target attribute.
Installing xdg-utils (xdg-open 1.1.3) did not resolve it.

Turns out that xdg-open does not automatically use the Windows browser, but you can install a WSL browser or xdg-open workaround like this one: https://github.com/cpbotha/xdg-open-wsl (untested).

yarn run v1.22.21
$ tauri info

[✘] Environment
    - OS: Ubuntu 22.4.0 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.44.3
    ✘ rsvg2: not installed
      Visit https://v2.tauri.app/start/prerequisites/ to learn more about tauri prerequisites
    ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
    ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.11.0
    - yarn: 1.22.21
    - npm: 10.2.4

[-] Packages
    - tauri 🦀: 2.0.3
    - tauri-build 🦀: 2.0.1
    - wry 🦀: 0.46.0
    - tao 🦀: 0.30.3
    - @tauri-apps/api : 2.0.2
    - @tauri-apps/cli : 2.0.3

[-] Plugins
    - tauri-plugin-shell 🦀: 2.0.1
    - @tauri-apps/plugin-shell : 2.0.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: Linux priority: 2 medium status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
Status: 📬Proposal
Development

No branches or pull requests

6 participants