Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] [MacOS] Webview issues on Intel Mac #13141

Open
mccordryan opened this issue Apr 4, 2025 · 1 comment
Open

[bug] [MacOS] Webview issues on Intel Mac #13141

mccordryan opened this issue Apr 4, 2025 · 1 comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@mccordryan
Copy link

Describe the bug

On some Intel Macs, the webview environment behaves in unintended ways that break the functionality of the app. We are running a Next JS frontend if relevant. More specifically:

  1. Frontend tauri checks fail. Because of this, components which should be web-only are rendering in the Tauri app. I am not sure if this is because window.__TAURI__ is undefined, or if there are deeper issues with accessing the window.

  2. State based forms are broken. We have a lightweight form using React's useState hook to track email & password values. When a valid email address & password > 8 chars are entered, the submit button turns from disabled to enabled. The inputs are filled without issue, but even with valid values, the disabled status never changes. In normal circumstances, it is recalculated on every state change. I don't know if the underlying states are failing to be set, or if the <button> disabled prop is failing to recalculate.

  3. Other various breaking errors which are caught by our error boundary. The stack trace is not comprehensible (hence why I have excluded it below), merely referencing meaningless hexadecimal webpack chunk names.

Overall, I am leaning towards this being an issue with Tauri's webview, seeing as the website alone has no issues for the affected users regardless of browser. Any help would be greatly appreciated!

Reproduction

We are unable to reproduce the behavior. It happens exclusively on Intel Macs, but not on the Intel Macs we have tried to replicate it on. If you would like to try for yourself:

  1. Configure a Tauri App and generate a universal MacOS build. (not sure if front end framework is relevant, but we are using Next JS)

  2. Run the app on an Intel Mac.

  3. window.__TAURI__ will remain undefined, and state updates will not work (provided you are lucky enough to have successfully recreated it).

Expected behavior

window.__TAURI__ should eventually evaluate to a non-undefined value as it does on darwin aarch64 & windows builds. Same with state updates.

Full tauri info output

[✔] Environment
    - OS: Mac OS 15.1.0 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.85.1 (4eb161250 2025-03-15)
    ✔ cargo: 1.85.1 (d73d2caf9 2024-12-31)
    ✔ rustup: 1.28.1 (f9edccde0 2025-03-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 18.18.0
    - pnpm: 9.12.3
    - yarn: 1.22.19
    - npm: 9.8.1

[-] Packages
    - tauri 🦀: 2.4.1
    - tauri-build 🦀: 2.1.1
    - wry 🦀: 0.50.5
    - tao 🦀: 0.32.8
    - @tauri-apps/api : 2.4.1
    - @tauri-apps/cli : 2.4.1

[-] Plugins
    - tauri-plugin-window-state 🦀: 2.2.2
    - @tauri-apps/plugin-window-state : 2.2.2
    - tauri-plugin-shell 🦀: 2.2.1
    - @tauri-apps/plugin-shell : 2.2.1
    - tauri-plugin-http 🦀: 2.4.3
    - @tauri-apps/plugin-http : 2.0.0-rc.2 (outdated, latest: 2.4.3)
    - tauri-plugin-autostart 🦀: 2.3.0
    - @tauri-apps/plugin-autostart : 2.3.0
    - tauri-plugin-dialog 🦀: 2.2.1
    - @tauri-apps/plugin-dialog : not installed!
    - tauri-plugin-updater 🦀: 2.7.0
    - @tauri-apps/plugin-updater : 2.0.0-rc.2 (outdated, latest: 2.7.0)
    - tauri-plugin-single-instance 🦀: 2.2.3
    - @tauri-apps/plugin-single-instance : not installed!
    - tauri-plugin-fs 🦀: 2.2.1
    - @tauri-apps/plugin-fs : not installed!
    - tauri-plugin-os 🦀: 2.2.1
    - @tauri-apps/plugin-os : not installed!
    - tauri-plugin-deep-link 🦀: 2.2.1
    - @tauri-apps/plugin-deep-link : 2.2.1
    - tauri-plugin-process 🦀: 2.2.1
    - @tauri-apps/plugin-process : not installed!
    - tauri-plugin-store 🦀: 2.2.0
    - @tauri-apps/plugin-store : not installed!

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

Stack trace


Additional context

  • All affected users can interact with the web version (straight Next JS) without issue. Confirmed to work for them in Safari, Firefox, and Chrome.

  • All affected users are running MacOS 10.15 or higher, which AFAIK should be compatible with Tauri.

  • While we have error reporting set up through Sentry (including on the Tauri end, not just the Next JS environment), nothing comes through. Presumably, this too is not working.

  • I thought it may have been an issue with javascript being disabled, but running a test build where javascript is manually disabled does not produce the same output (it hangs indefinitely on our loading screen).

@mccordryan mccordryan added status: needs triage This issue needs to triage, applied to new issues type: bug labels Apr 4, 2025
@FabianLars
Copy link
Member

Can you get their macos version numbers and share them here?

Didn't ever see a webview difference between Intel and arm iirc but the webview version is bound to the macos version (so checking it in safari is kinda useless as well here)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
None yet
Development

No branches or pull requests

2 participants