Opening a webpage with WebviewWindow encounters an error STATUS_ACCESS_VIOLATION.

[cck190891]

Hi everyone,

I encountered a little issue while using Tauri. I wanted to ask whether this is a bug or something specific to my setup.

After the release of Tauri v2.0.0-beta.14, I eagerly upgraded my program from beta.8 because beta.14 fixed the issue of webviews not being created. However, just when everything seemed to be going well, I found that although my program could create webviews normally, the web page would crash with the error code STATUS_ACCESS_VIOLATION.This didn't occur in beta.8.

This issue is almost nonexistent on text web pages, but it occurs almost 100% of the time on video streaming platforms like YouTube and Twitch. Additionally, on websites with Cloudflare verification, it leads to verification failure.

After testing, I found that the issue occurs with.plugin(tauri_plugin_notification::init()). Removing this line resolves all the problems.

Since it seems to be related to tauri_plugin_notification, I reported it here. Can anyone help?

Thank you very much!!

[WalrusSoup]

Encountering this as well on production builds, exclusively. Dev seems to work fine.

[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 126.0.2592.87
    ✔ MSVC: Visual Studio Community 2022
    ✔ 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-x86_64-pc-windows-msvc (default)
    - node: 21.7.2
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.23
    - tauri-build [RUST]: 2.0.0-beta.18
    - wry [RUST]: 0.41.0
    - tao [RUST]: 0.28.1
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.21

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

Breakpoint at backend is_permission_granted is hit - webview crashes when returning call to the frontend.

[tance77]

This issue is stell present in tauri 2.0.0-beta.23

[FabianLars]

Did somebody try to repro this in a more minimal environent like a new CTA app? I'm having issues reproducing this so i assume there's a condition here i'm not seeing.

[cck190891]

@FabianLars This is how I reproduce the issue. For your reference.

PS D:\Visual_studio\Tauri>  pnpm create tauri-app --beta 
../../.pnpm-store/v3/tmp/dlx-17380       |   +2 +
../../.pnpm-store/v3/tmp/dlx-17380       | Progress: resolved 12, reused 2, downloaded 0, added 2, done
✔ Project name · tauri-app
✔ Choose which language to use for your frontend · TypeScript / JavaScript - (pnpm, yarn, npm, bun)
✔ Choose your package manager · pnpm
✔ Choose your UI template · React - (https://react.dev/)
✔ Choose your UI flavor · JavaScript
✔ Would you like to setup the project for mobile as well? · no

cd tauri-app pnpm install

add tauri-plugin-notification = "2.0.0-beta" to Cargo.toml add .plugin(tauri_plugin_notification::init()) to main.rs add <a href='test url'>Open </a> to App.jsx For the test url, you can use YouTube or Twitch URLs.

I tested on tauri-beta.23, and the same issue I described still occurs.

Below is tauri info:

[✔] Environment
    - OS: Windows 10.0.19045 X64
    ✔ WebView2: 126.0.2592.87
    ✔ MSVC: Visual Studio Build Tools 2022
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.10.0
    - pnpm: 8.15.1
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 2.0.0-beta.23
    - tauri-build [RUST]: 2.0.0-beta.18
    - wry [RUST]: 0.41.0
    - tao [RUST]: 0.28.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.14
    - @tauri-apps/cli [NPM]: 2.0.0-beta.21

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

[WalrusSoup]

I pulled it locally for testing and added some console.logs - i can't seem to break using debugger because the rollup process removes it and the window launches too fast before devtools.

One thing to note - we are connecting to a remote external URL when doing this. That is the only way this crashes. When we launch localhost, it runs fine.

(unknown) isPermissionGranted() default
(unknown) isPermissionGranted() entry calling plugin:notification|is_permission_granted
(unknown) true
(unknown) void isPermissionGranted() response true
(unknown) void isPermissionGranted() response is not null
(unknown) setNotificationPermission() granted
(unknown) setNotificationPermission() window.notification.permission set
(unknown) setNotificationPermission() permissionSettable set to false
index-C2VP2neN.js:703 unregistering
index-C2VP2neN.js:703 registering
index-C2VP2neN.js:703 requesting machine info
index-C2VP2neN.js:703 starting monitoring loop
// redacted
(unknown) isPermissionGranted() default
(unknown) isPermissionGranted() entry calling plugin:notification|is_permission_granted
(unknown) isPermissionGranted() default
(unknown) isPermissionGranted() entry calling plugin:notification|is_permission_granted

So here is where we get even stranger - if i set a breakpoint on is_permission_granted in the application, i only ever see it fire once (the subsequent 2 calls are rejected by tauri? die somewhere upstream?)

If I set a breakpoint and just let the backend hold it there, the frontend still crashes with the same state and the log file still shows two additional calls happen before the window implodes. The first call never returns, as expected (because I held it there)

If I replace this function with a simple Promise.resolve(true) - the app will not crash.

[tance77]

Windows Only

@FabianLars Here is the minimum reproduction repo. This only happens on the built version of Windows the repo and connecting to a remote URL. For testing purposes, I connected it to our preview branch front-end assets. It would most likely work with another remote URL. I haven't tested it.

Minimum Reproduction Repo

https://github.com/tance77/notification-bug

Steps to Reproduce

git clone https://github.com/tance77/notification-bug
cd notification-bug
npm i
npm run tauri build

Open the exe in /src-tauri/target/release

tauri info

[✔] Environment
    - OS: Windows 10.0.22621 X64
    ✔ WebView2: 126.0.2592.87
    ✔ MSVC:
        - Visual Studio Build Tools 2017
        - Visual Studio Build Tools 2022
    ✔ 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-x86_64-pc-windows-msvc (default)
    - node: 18.14.0
    - npm: 9.3.1

[-] Packages
    - tauri [RUST]: 2.0.0-beta.23
    - tauri-build [RUST]: 2.0.0-beta.18
    - wry [RUST]: 0.41.0
    - tao [RUST]: 0.28.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.14
    - @tauri-apps/cli [NPM]: 2.0.0-beta.21

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

Edit:

I did try changing the remote URL to https://youtube.com/ and the same result happened

[FabianLars]

Thanks for the repro!! I'm quite busy over the weekend so i don't know when exactly i'll be able to look into it (it's high on my prio list tho)

[tance77]

Any progress on fixing this bug?

[FabianLars]

Nope, like i said i was unavailable over the weekend, and mondays are always busy as hell. I'll look into it tomorrow morning.

That said, i can at least confirm that i see the same issue using your repro, so thanks for that.

[FabianLars]

So i can't really tell what's really causing this, maybe chromium doesn't like that we call fetch inside the permission request, at least on "normal" origins (instead of our custom origin if you're not loading remote websites).

Currently i'd just lean towards having an OS check in the init js script and iterate later when we use webview2's permission apis. The Rust end always returns Granted anyways 🤷

[FabianLars]

@WalrusSoup

If I replace this function with a simple Promise.resolve(true) - the app will not crash.

Did notifications work afterwards?

[WalrusSoup]

@WalrusSoup

If I replace this function with a simple Promise.resolve(true) - the app will not crash.

Did notifications work afterwards?

No issue on this end when just returning true.

I think lazily evaluating the permissions when the actual function to show a notification is called may resolve it too. I have no idea why it fires two additional times when loading.

https://github.com/user-attachments/assets/bb6fa070-34ce-4c49-99e9-54a5b03501f2

[FabianLars]

I think lazily evaluating the permissions when the actual function to show a notification is called may resolve it too. I have no idea why it fires two additional times when loading.

Ahhh, i missed the last part of the init script where we check the permission state. I assume it's there for a reason but i'll look into that tomorrow.

No idea why it fires multiple times either. Are you loading iframes maybe?

[WalrusSoup]

No idea why it fires multiple times either. Are you loading iframes maybe?

IFRAMES!

Our app has Sentry performance monitoring with playback support. If i break on the second\third iteration of this, I do see that higher on the stack from the additional function calls does appear to be from Sentry.

It looks like the actual problem zone is located here which decides if the environment supports fetch natively by injecting an iframe into the header.