[bug]: Password managers (Bitwarden/1Password) can't autofill the sign-in password field — autocomplete="off" on auth inputs regresses WCAG 1.3.5
@vihar is already working on this.
Since Sep 2, 2026.
- Dominant language
- TypeScript
- Stars
- 59.6k
- Forks
- 5.8k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 49
Description
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 fieldautoComplete="off"(L216), confirm_passwordautoComplete="off"(L253)apps/web/core/components/account/auth-forms/email.tsx— email fieldautoComplete="off"(L77)- mirrored across admin/space auth forms and
packages/uiauth-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
- Have a Plane login saved in Bitwarden or 1Password for your instance URL.
- Open the sign-in page, enter email, continue to the password step.
- Observe: no autofill suggestion on the password field.
Environment
- Plane: self-hosted,
preview(reproduced against currentpreviewsource) - 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.