Pairing with a typed or pasted API key triggers iOS's system "Save Password?" AutoFill dialog, offering to store the key in the iCloud Keychain as if it were a website password.
That is wrong for users — an API key is not a password for a site, and the dialog names neither the server nor what is being saved — and it is the root cause of the E2E pairing flakiness tracked separately (see below).
Verified state
Checked 2026-09-05 against iOS E2E run 33940567423 (iPhone 17 Pro / iOS 26, Release build).
The dialog is visible in the run's own artifact, launch/screenshots/step-027-tapOnElement-pair-confirm-add-btn.png: the "Save Password?" sheet sits over the pairing confirm screen while "Add server" is still on screen behind it.
The trigger is the API-key field in components/servers/ServerFormFields.tsx:188:
secureTextEntry={!showApiKey}iOS treats a submitted secureTextEntry field as a credential worth offering to save. The field sets autoCapitalize, autoCorrect and returnKeyType, but nothing that opts out of AutoFill.
Why it matters beyond the annoyance
A system alert renders in its own window, so while it is up the app's accessibility tree is unreachable. In that run the tree returned 11 nodes — status bar and progress indicators only — and the tap meant for pair-confirm-add-btn went to the dialog's window instead.
Fix direction — needs verification, not assumed
The candidates are textContentType and/or autoComplete on that TextInput. Which value actually suppresses the prompt on iOS 26 is a system heuristic, so it should be confirmed on a simulator or device before being committed rather than picked from memory.
Whatever is chosen must not break the show/hide toggle (server-form-toggle-api-key) or paste (server-form-paste-key).
Related
Pairing with a typed or pasted API key triggers iOS's system "Save Password?" AutoFill dialog, offering to store the key in the iCloud Keychain as if it were a website password.
That is wrong for users — an API key is not a password for a site, and the dialog names neither the server nor what is being saved — and it is the root cause of the E2E pairing flakiness tracked separately (see below).
Verified state
Checked 2026-09-05 against iOS E2E run 33940567423 (iPhone 17 Pro / iOS 26, Release build).
The dialog is visible in the run's own artifact,
launch/screenshots/step-027-tapOnElement-pair-confirm-add-btn.png: the "Save Password?" sheet sits over the pairing confirm screen while "Add server" is still on screen behind it.The trigger is the API-key field in
components/servers/ServerFormFields.tsx:188:iOS treats a submitted
secureTextEntryfield as a credential worth offering to save. The field setsautoCapitalize,autoCorrectandreturnKeyType, but nothing that opts out of AutoFill.Why it matters beyond the annoyance
A system alert renders in its own window, so while it is up the app's accessibility tree is unreachable. In that run the tree returned 11 nodes — status bar and progress indicators only — and the tap meant for
pair-confirm-add-btnwent to the dialog's window instead.Fix direction — needs verification, not assumed
The candidates are
textContentTypeand/orautoCompleteon thatTextInput. Which value actually suppresses the prompt on iOS 26 is a system heuristic, so it should be confirmed on a simulator or device before being committed rather than picked from memory.Whatever is chosen must not break the show/hide toggle (
server-form-toggle-api-key) or paste (server-form-paste-key).Related