Open anatawa12 opened 2 months 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.
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
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.
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 🤷
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?
Hmm yeah, I wouldn't mind that. Do you have an implementation approach in mind? Just hardcode /usr/bin/xdg-open
?
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.
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
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
outputStack trace
No response
Additional context
Downstream issue: vrc-get/vrc-get#934