You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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:
Configure a Tauri App and generate a universal MacOS build. (not sure if front end framework is relevant, but we are using Next JS)
Run the app on an Intel Mac.
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.
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).
The text was updated successfully, but these errors were encountered:
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)
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:
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 thewindow
.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.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:
Configure a Tauri App and generate a universal MacOS build. (not sure if front end framework is relevant, but we are using Next JS)
Run the app on an Intel Mac.
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
outputStack 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).
The text was updated successfully, but these errors were encountered: