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

[anatawa12]

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]

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]

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]

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]

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]

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]

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

[hypevhs]

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]

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

[betamos]

+1 on opt-out of xdg-open bundling. It gets exponentially more complicated, because I get different behaviors with:

• AppImage built locally on my dev machine (later Ubuntu)
• AppImage built in CI which uses old base image as per recommendations (do I need to have xdg-utils installed? - it's not documented).
• At runtime, depending on what the user has

I've seen everything from silent failures on some file types, and urls, to errors, to opening in different applications (Chrome instead of Firefox, for me), to different behavior based on changing XDG_DATA_DIRS env var.

It's a mess, and this isn't Tauri's fault. But, I would say that it's much preferable to deal with explicit errors (which later versions of xdg-open give, and also if xdg-open is not available). At least then we can tell the user "hey we tried to open this link, but it didn't work so here you can open it manually".

Sure, there might be a set of users who don't have xdg-utils installed. But the version on the old ubuntu base image (20.04) is so bad and inconsistent that I'd rather have it work for most/modern/correctly set up systems, and provide some troubleshooting docs on the side.

[FabianLars]

opened a pr earlier today, forgot to link this issue tho https://github.com/tauri-apps/plugins-workspace/pull/2103 for now it's just really simply trying to call /usr/bin/xdg-open on the system and not inside the appimage (falling back to the old behavior)

Another thing that we need to check there is the mentioned XDG_DATA_DIRS env var, this one iirc is also a problem in appimages (because the runtime sets it to something appimage specific).

In theory the more correct approach would be to use an exec wrapper but i never was able to integrate them without causing even more issues (especailly due to webkitgtk) so i hope the simple approach here works as well.

btw i'd appreciate it if someone could test the pr

as long as we're using webkitgtk inside appimages (it really doesn't want to), better solutions are not worth my time at the moment.

[betamos]

@FabianLars awesome, thanks for linking the issues.

Reading up a bit: https://www.freedesktop.org/wiki/Software/xdg-utils/#usingxdg-utils

TL;DR: They actually do recommend bundling the xdg utils.

There could be issues with hardcoding /usr/bin/xdg-open, when it should probably be found in the PATH. However, does anyone understand the AppImage specifics around this? If AppImage relies on a self-contained notion of an app, perhaps the right way is actually bundling.. The issue is the old version, that fails silently and other stuff.

If we can bundle the new version (it is backward compatible), perhaps we should do that?

See also: https://github.com/AppImage/AppImageKit/issues/396

I'm gonna ask the appimage folks what they think.

[betamos]

Unfortunately this was really hard and I couldn't find a solution. But I will share my research:

• AppImage runtime sets and/or alters a bunch of env vars, PATH, XDG_DATA_DIRS, LD_LIBRARY_PATH etc. God knows what.
• This env is used when starting subprocesses, by default

On my Ubuntu 22.04 local machine with Tauri 1.8.1, xdg-open 1.1.3, this results in:

• I didn't have xdg-open bundled in the appimage dir, suggesting it's not bundled by Tauri
• Opening files works, suggesting my system xdg-open is found
• ...but URLs simply don't open. I do not get a JS error.

I've found some more issues/writing about this, and seemingly the suggestion is to restore/clean up the env prior to launching. I have not verified this myself:

• One solution is to restore the env through /proc/[pid]/environ on the parent process, before launching the subprocess.
• Another one is to remove all known AppImage prefixes from the environment with regex

Personally, I went with a different workaround:

1. Make the shell.open(url) call
2. Wait 1s
3. Check window focus. If still in focus, copy the URL to clipboard and notify the user so they can manually paste it.

This is obviously very dumb. But, if the link can't be opened, it's very serious. And since there's a risk of silent errors here, I'd rather take the false positives and allow users to make progress.