Repository navigation
[Bug]: Desktop (macOS): stacked native "server is temporarily out of service (405)" alerts, each Cancel/OK dismisses only one #14195
Description
Activity
Triage
This dialog is not T3 Code, Squirrel.Mac, or electron-updater. The sentence is the ZK Framework client’s retry confirm, and Electron is presenting it as a native macOS alert because it is running inside this app.
ZK builds it in
zAu.confirmRetryasFAILED_TO_RESPONSE, a newline,TRY_AGAIN, then a parenthesized status:The server is temporarily out of service. Would you like to try again? (405)FAILED_TO_RESPONSEis"The server is temporarily out of service."andTRY_AGAINis"Would you like to try again?"(msgzk.js).jq.confirmiswindow.confirm(dom.ts). The number in parentheses is the failed AU request’s HTTP status (au.ts):405means that request got Method Not Allowed, and0means it failed before an HTTP status (network error, abort, or similar) with an empty status text. OK tells ZK to resend that request, so the same dialog can come straight back.Nothing in
apps/orpackages/uses this copy. The updater’s own alerts are “You're up to date!”, “Update check failed”, and “Updates unavailable” (apps/desktop/src/window/DesktopApplicationMenu.ts). The desktop asset handler does return an empty405for non-GET/HEAD ont3code://(apps/desktop/src/electron/ElectronProtocol.ts), but that response is never turned into this alert.The only place this script can run inside the
t3codeprocess is the in-app browser.window.confirmfrom a<webview>is an app-modal native dialog, titled with the app name, with Cancel and OK.will-attach-webviewonly locks down the guest (apps/desktop/src/window/DesktopWindow.ts); it does not interceptalert/confirm/prompt. Each guest web-contents can have one of these up, and on macOS the alert runs a nested modal loop, so several land on top of each other. Cancel or OK only answers the top one. A background browser tab still runs timers (setBackgroundThrottling(true)slows them, it does not stop them), which matches this showing up during ordinary use with no obvious click.The 405/0 is that ZK page’s AU call failing, not the T3 server being down. The T3 bug is that a guest page’s
confirm()is allowed to stack app-modal dialogs over the whole desktop app.When it happens again, check the browser panel for every open tab, including ones that are not focused, and reply with the URL (host is enough). If no browser tab is open, this explanation is wrong and we should keep looking.
Thanks my bad, sorry for the inconvenience.
Before submitting
Area
apps/desktop
Steps to reproduce
No deterministic trigger yet. It happens repeatedly during normal use.
Expected behavior
At most one alert is shown, and dismissing it (Cancel or OK) removes it. A background failure like this should not interrupt with a modal at all.
Actual behavior
3 to 5 identical native macOS alerts stack on top of each other:
The same alert also shows up with
(0)instead of(405).Cancel and OK each dismiss only the top alert, so I have to click through 3 to 5 dialogs every time it happens.
This text does not appear anywhere in the T3 Code source (
apps/,packages/), so the alert is probably not our owndialog.showMessageBox. It looks like a native macOS networking/system alert raised inside the Electron process, maybe from the update path (Squirrel.Mac / electron-updater download) or another background request that triggers repeatedly. Not confirmed.Impact
Major degradation or frequent failure
Version or commit
0.0.43-nightly.20260923.2135
Environment
macOS (Darwin 25.6.0), T3 Code Desktop nightly
Workaround
None. Click through every alert.