tauri-apps / tauri

Build smaller, faster, and more secure desktop applications with a web frontend.
https://tauri.app
Apache License 2.0
81.22k stars 2.43k forks source link

[bug] tauri.shell.open does not working on differtent linux distribution than building platform with appimage build #10078

Open anatawa12 opened 2 months ago

anatawa12 commented 2 months ago

Describe the bug

One of user told me that buttons opens brower does not works on Arch Linux with AppImage built on GitHub Actions.

After small investigation, open function become not working if running on other distributions than the AppImage was built.

Reproduction

Downloading https://github.com/anatawa12/tauri-link-appimage-test/releases/tag/app-v0.1.0 and run on Arch Linux will reproduce this problem and downloading https://github.com/vrc-get/vrc-get/issues/934#issuecomment-2164885456 and run on Ubuntu 24.04 will also reproduce this problem

Expected behavior

It should works

Full tauri info output

[✔] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10)
    ✔ cargo: 1.79.0 (ffa9cf99a 2024-06-03)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.12.2
    - pnpm: 8.15.4
    - yarn: 1.22.19
    - npm: 10.8.1

[-] Packages
    - tauri [RUST]: 1.6.8
    - tauri-build [RUST]: 1.5.2
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - tauri-cli [RUST]: 1.5.14
    - @tauri-apps/api [NPM]: 1.5.6
    - @tauri-apps/cli [NPM]: 1.5.14

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: out
    - devPath: http://localhost:3000/
    - framework: React (Next.js)
    - bundler: Webpack

Stack trace

No response

Additional context

Downstream issue: vrc-get/vrc-get#934

anatawa12 commented 1 month ago

According to @hypevhs in vrc-get/vrc-get#1251, bundling xdg-open script causes this problem so it might be good to have option to disable bundling xdg-open?

I feel it's better to use xdg-open of user environment than using it of build environment.

FabianLars commented 1 month ago

I feel it's better to use xdg-open of user environment than using it of build environment.

This is not really how appimages work but i guess with the amount of issues we have with appimages it makes sense to expose this to devs. Should be a pretty simple change, we can just check if the APPIMAGE_BUNDLE_XDG_OPEN env var is already set in the cli before setting it to 1

hypevhs commented 1 month ago

Can I ask, what were the problems for which the solution was to copy in xdg-open instead of trusting the host to provide it? Given that xdg-open usually just forwards the request to some other executable on the host (kde-open, gio), I can't think of a reason why including it would improve compatibility.

FabianLars commented 1 month ago

I'm away over the weekend so I can't link any sources (idk if they were public), but the main reason was that we actually got reports from users that did not have xdg-open installed. I doubt that this was their last problem or that bundling xdg-open helped that much, but since that's how appimages work we simply opted for bundling it.

I could also swear that a user had version mismatch issues without this change but that system was probably just messed up or I'm mixing things up 2 yrs later 🤷

hypevhs commented 1 month ago

I just tried Lettura (RSS reader with an AppImage and a few code paths that call shell.open) and it has the same issue. So it's not that shell.open is broken in some tauri apps, it's that it's broken in all tauri apps for some users. We could certainly still add the build-time opt-out switch, or even provide a similar runtime opt-out switch for users, but rather than wait for the devs & users of each app to stumble over this issue, I interpret this as an opportunity to rework the default behavior.

Shell.open could prefer the host's xdg-open, and if it doesn't exist, fall back to the bundled copy. WDYT?

FabianLars commented 1 month ago

Hmm yeah, I wouldn't mind that. Do you have an implementation approach in mind? Just hardcode /usr/bin/xdg-open?

hypevhs commented 1 month ago

Maybe instead of hardcoding a full path, could just name the bundled copy "xdg-open-fallback". Try to run xdg-open, and if not found, run xdg-open-fallback.

anatawa12 commented 1 month ago

After workarounding this issue by using open crate directly, kde-oen invoked in xdg-open become not working due to Library version conflict with bundled one and system one so we also should fix problem I think.

In my app, by removing AppDir entries from LD_LIBRARY_PATH, I workarounded thia problem.

https://github.com/vrc-get/vrc-get/pull/1260#issuecomment-2242153215