mirror of
https://github.com/karatektus/pl_mail.git
synced 2026-10-25 01:54:10 +00:00
Paul LütznerandClaude Opus 5.5
855d0faedc
Reported from Admin → SSO after the previous fix: Chrome no longer filled the saved login in on load, but a click in the client secret still listed every saved password, Bitwarden offered to generate a password into it, and Bitwarden opened its menu in "Name on the button" and "Scopes" below. All of it follows from the field being type="password", and three rounds of attributes each moved the symptom. `off` is ignored by Chrome on a password field. `new-password` stops the fill and makes Bitwarden read the form as a sign-up. The vendor opt-outs stop extensions filling and not Bitwarden's menu opening. So client secrets, API tokens and mail-server passwords are a new SecretType: a text input drawn as dots by CSS, never rendered back, not trimmed. With no password input in the form there is nothing to classify. The sign-in form, the first administrator's password and the change-password form stay real password inputs, where offering to save is the point. Bitwarden's menu in the two text fields had a second cause: they were the only ones with no `autocomplete` at all, and the two that said `off` were left alone. The form theme now says `off` for every text field that asks for nothing. PasswordManagerIgnore::SECRET goes; nothing uses it. The test added with the previous fix is replaced by two: a secret renders as masked text and comes back empty, and no form outside the three login ones uses PasswordType. Checked in a browser that the field masks and the frame holds no password input. Not checked: Bitwarden and Chrome's password manager themselves, which this environment does not have. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>