tauri
tauri copied to clipboard
[bug] Browser crash when opening url from Tauri on Linux
Describe the bug
When clicking on an anchor tag on a Tauri app that opens on _blank the browser may throw an error and not even open the tab (in the case of chromium-based) or it opens the tab anyways after the error being thrown (in the case of firefox).
Reproduction
- Set up a Fedora Workstation environment with a NVIDIA graphics card and use Wayland
- Click on any anchor tag on a Tauri application
- ABRT should report the error immediatelly
Expected behavior
No response
Platform and versions
N/A
I can create a dev build of the application I'm testing in a few days, but the error was thrown using https://github.com/probablykasper/kadium/ and it really doesn't look like a problem with the application code.
Stack trace
No response
Additional context
Weirdly I can only reproduce this error on a very specific environment: Fedora Workstation 36 with NVIDIA graphics drivers under Wayland. I'm not really sure how to continue with debugging this so I decided to open this bug report. This is the error information after the browser crashes, I'll see if I can grab a stack trace later to complete this bug report:
More information about trying to found out what causes this problem here: https://github.com/probablykasper/kadium/issues/4
Thanks for reporting :+1: I believe you have this issue when using the AppImage bundled by Tauri right? Would you be ok sharing the resulting AppImages created:
- On the problem environment
- And a working environment?
And something worth testing would be,
Fedora Workstation 36 live install using GNOME Boxed (QEMU) works out of the box without ABRT throwing any errors, so this is very likely related to NVIDIA-something on the system.
The AppImage produced in this environment, does it cause the issue for you when you launch this bundle on the problem environment (your Nvidia&Wayland install)? This should help narrow down if it's a problem happening at the bundling stage, or whether it has to do with the runtime environment.
Finally for good measure, tauri info
would be great.
(The recent v1.0.1
release has included a number of AppImage fixes as well.)
Ah, just realizing you might not be building @DoodlesEpic. Let me know if this was all results from the same AppImage released here https://github.com/probablykasper/kadium/releases/tag/v1.4.0
@DoodlesEpic it's tough to reproduce the crashes you're seeing. I've tried a Fedora, Wayland, Nvidia live iso but it didn't have those crashes. However I think I've tracked the problem and made a small app to try and prove it with a workaround.
Can you try running this AppImage here https://github.com/Beanow/poc-tauri-issue/releases/tag/poc-v0.1.0
It should come as a small window with links to open in a browser. With the workaround disabled (red) both links should cause the issue you're seeing now. Workaround enabled (green) the links should open your default browser normally, if I got the cause right :crossed_fingers:
Ah, just realizing you might not be building @DoodlesEpic. Let me know if this was all results from the same AppImage released here https://github.com/probablykasper/kadium/releases/tag/v1.4.0
Indeed, sorry for not providing some repro environment for the issue
@Beanow You are a frigging genius, yeah the workaround works perfectly, no errors thrown and both target="_blank" and shell:open() work nicely with it enabled. Of course the error is thrown with both without using the workaround.
The AppImage produced in this environment, does it cause the issue for you when you launch this bundle on the problem environment (your Nvidia&Wayland install)? This should help narrow down if it's a problem happening at the bundling stage, or whether it has to do with the runtime environment.
I've also created a build on my local dev environment, the error is indeed only thrown when running the application from an AppImage.
yarn run v1.22.15
$ tauri info
Environment
› OS: Fedora 36.0.0 X64
› Node.js: 16.15.1
› npm: 8.13.2
› pnpm: 6.11.0
› yarn: 1.22.15
› rustup: 1.24.3
› rustc: 1.61.0
› cargo: 1.61.0
› Rust toolchain: stable-x86_64-unknown-linux-gnu
Packages
› @tauri-apps/cli [NPM]: 1.0.1
› @tauri-apps/api [NPM]: 1.0.1
› tauri [RUST]: 1.0.1,
› tauri-build [RUST]: 1.0.1,
› tao [RUST]: 0.12.0,
› wry [RUST]: 0.19.0,
App
› build-type: bundle
› CSP: unset
› distDir: ../public
› devPath: http://localhost:8080/
› framework: Svelte
› bundler: Rollup
App directory structure
├─ .git
├─ .github
├─ .vscode
├─ public
├─ src-tauri
├─ src
└─ node_modules
That's fantastic @DoodlesEpic thanks for testing. Then I have a good suspect of what the cause is. :joy: please keep a snapshot of your desktop around, because I believe this will be nigh impossible to reproduce otherwise.
The problem most likely is because the external browser is launched from within the AppImage bundled context. And that will start the browser in a weird situation where some shared libraries will be taken from the AppImage, some from the system installed libraries.
The end result is some unpredictable mishmash of bundled and system libraries. And that would of course be worse on a system that's been used as a daily driver, vs a fresh live iso or vm install.
@DoodlesEpic I've got another build here to test an approach to fixing it. https://github.com/Beanow/tauri-appimg-building/releases/tag/hello-tauri-v0.1.0 In this build neither workaround enabled/disabled should crash.
@Beanow Yup, both work perfectly.
Thanks for validating. That gives enough info to detect the problem anywhere (no need for obvious crashes). I've discussed with the team what the solution might look like, though It'll take me some time to turn that into a PR.