[bug]: Password managers (Bitwarden/1Password) can't autofill the sign-in password field — autocomplete="off" on auth inputs regresses WCAG 1.3.5

[neilsoult]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Current behavior

On the sign-in screen, Bitwarden (and 1Password) do not offer to autofill the password field. The inline autofill suggestion does not appear and auto-on-load fill does not occur.

Root cause: every auth email/password input hard-codes autoComplete="off". This was introduced in PR #8517 ("[VPAT-27] chore(security): disable autocomplete on sensitive input fields"), which flipped the sign-in password field from autoComplete="on" to autoComplete="off".

Still present on preview:

• apps/web/core/components/account/auth-forms/password.tsx — password field autoComplete="off" (L216), confirm_password autoComplete="off" (L253)
• apps/web/core/components/account/auth-forms/email.tsx — email field autoComplete="off" (L77)
• mirrored across admin/space auth forms and packages/ui auth-form inputs

Expected behavior

Password managers offer autofill on the sign-in password (and pair it with the email/username). Autocomplete tokens describe the fields' purpose.

Why autocomplete="off" is the wrong fix

PR #8517 was filed as an accessibility/VPAT item, but autocomplete="off" on identity fields is itself a WCAG 2.1 SC 1.3.5 Identify Input Purpose (Level AA) failure. That success criterion requires programmatically identifiable input purpose via the HTML autocomplete tokens (username, current-password, new-password). Setting off removes that identification, so the change regresses the very criterion a VPAT is meant to track — in addition to breaking password managers and browser autofill for everyone.

autocomplete="off" also does not reliably prevent credential storage (Chrome/Firefox ignore it for password fields), so it does not achieve the stated security goal either.

Proposed fix

Use purpose tokens instead of off:

Field	Token
email / username	username
sign-in password	current-password
sign-up / set / reset password + confirm	new-password

The sign-in password.tsx field is shared between sign-in and sign-up via the mode prop, so it should be conditional:
autoComplete={mode === EAuthModes.SIGN_IN ? "current-password" : "new-password"}.

I have a patch for the apps/web auth forms ready and can open a PR. The same tokens should be mirrored to the admin/space forms and the packages/ui auth-form/password-input components that #8517 also touched.

Steps to reproduce

Steps to reproduce

1. Have a Plane login saved in Bitwarden or 1Password for your instance URL.
2. Open the sign-in page, enter email, continue to the password step.
3. Observe: no autofill suggestion on the password field.

Environment

• Plane: self-hosted, preview (reproduced against current preview source)
• Browser: any, with the Bitwarden or 1Password extension

Additional context

Related password-manager reports (different symptom — fill happens but React state/CSRF fails): #5116, #5421.

The deeper cause of flaky autofill is the two-step (identifier-first) form: the password field isn't in the DOM at page load. File separately as a fast-path proposal for password-only instances (single-screen login) - #9740

Environment

Deploy preview

Browser

Mozilla Firefox

Edition

Community

Version

v1.4.1

[makeplane]

Synced with Plane Workspace 🔄

[GIT-333] [bug]: Password managers (Bitwarden/1Password) can't autofill the sign-in password field — autocomplete="off" on auth inputs regresses WCAG 1.3.5

[makeplane]

Synced with Plane Workspace 🔄

[GIT-334] [bug]: Password managers (Bitwarden/1Password) can't autofill the sign-in password field — autocomplete="off" on auth inputs regresses WCAG 1.3.5