tauri-apps / tauri

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

[bug] WebView crashes on certain pages(STATUS ACCESS VIOLATION) #11432

Open kanatapple opened 1 month ago

kanatapple commented 1 month ago

Describe the bug

The WebView crashes when you load the certain page by doing the following in initialization script(WebviewWindowBuilder::initialization_script).

Initialization script

document.addEventListener('DOMContentLoaded', () => {
  window.__TAURI__.event.listen('test', (event) => {
    console.log(event);
  });
});

URL

https://st.id.softbank.jp/sbid_auth/type1/2.0/authorization.php?response_type=code&client_id=yPXPPaM2ccrUxdLtHV5VEgbJ3jGeDGic&redirect_uri=https://bff-top.crth.st.bene-st.jp/v1/top/sb-pre-auth-start&state=36eaf7a1-5103-45cf-93ba-97cb642519f2&scope=openid+cdp&nonce=0797f0f2-c821-4f19-8502-ccd789673704&acr_value=1

I don't know if it will crash with other URLs, but it will definitely crash with the above URL.

Reproduction

https://github.com/kanatapple/tauri-status-access-violation.git

  1. yarn
  2. yarn tauri dev

Expected behavior

The page loads without crashing.

Full tauri info output

[✔] Environment
    - OS: Windows 10.0.19045 x86_64 (X64)
    ✔ WebView2: 129.0.2792.89
    ✔ MSVC:
        - Visual Studio Professional 2017
        - Visual Studio Professional 2019
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.17.0
    - yarn: 1.22.11
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.0.5
    - tauri-build 🦀: 2.0.1
    - wry 🦀: 0.46.2
    - tao 🦀: 0.30.3
    - tauri-cli 🦀: 1.2.3
    - @tauri-apps/api : 2.0.2
    - @tauri-apps/cli : 2.0.3

[-] Plugins

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

Stack trace

No response

Additional context

No response

Legend-Master commented 1 month ago

I can reproduce this, seems like any __TAURI_INTERNALS__.invoke("") call on DOMContentLoaded would crash on this site, doesn't seem to happen if I put this call inside a setTimeout with 10ms delay inside or outside DOMContentLoaded event listener, doesn't seem to happen on a few other sites I tested

I don't have a clue on the cause to be honest

ahqsoftwares commented 4 weeks ago

I can reproduce this, seems like any __TAURI_INTERNALS__.invoke("") call on DOMContentLoaded would crash on this site, doesn't seem to happen if I put this call inside a setTimeout with 10ms delay inside or outside DOMContentLoaded event listener, doesn't seem to happen on a few other sites I tested

I don't have a clue on the cause to be honest

We can just add a timeout to the implementation of that window invoke I guess?

Legend-Master commented 4 weeks ago

I don't think we can just simply wrap invoke in a setTimeout, still need more digging to understand why this is happening

But for a user side workaround, this should work for now