Revealed passwords should change back to password type when submitting the form

[jamieburchell]

Taking the lead from the UK gov recommendations on implementing password reveal option, they say:

When the form is submitted, the password input should automatically change its type to password, if it has not already done so. This is to prevent browsers from remembering it as a previously-provided value and potentially displaying it as an autofill option on non-password inputs.

Source: ​https://design-system.service.gov.uk/components/password-input/#define-the-inputs-type-as-password

Currently, the input type remains as text (plain) when submitting a form that has a revealed password.

Trac ticket: https://core.trac.wordpress.org/ticket/62147

[vgnavada]

Test Report

Description

I've tested the patch on WordPress Playground, and it's functioning as expected. ✅

When I enter the password in the field, the input type initially will be 'text'

And once I toggle the eye icon or click the login button, the input type automatically changes to 'password'.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8223

Environment

• WordPress: 6.8-alpha-20250130.101504
• PHP: 7.4.31-dev
• Server: PHP.wasm
• Database: WP_SQLite_Translator (Server: 5.5 / Client: 3.40.1)
• Browser: Chrome 134.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

Supplemental Artifacts

Added Inline

[narenin]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested:

​https://github.com/WordPress/wordpress-develop/pull/8223

Environment

OS: macOS 14.6.1
Web Server: PHP.wasm
PHP: 7.4.31-dev
WordPress: 6.8-alpha-20250130.101504
Browser: Chrome Version 133.0.6943.142
Theme: Minimal Child Theme Version 1.0.2

Actual Results

When I have entered the password in the field, the input type initially will be 'text'.

And once I have toggled the eye icon or click the login button, the input type automatically changes to 'password'.

✅ Issue resolved with patch.

[jamieburchell]

Does the patch apply to ALL password fields, or just the login page? It would also need to apply to the edit user page, change password, etc?

[vgnavada]

Hi @jamieburchell ,

Good point, Thanks for this.

Well, yes, I just checked the same PR for the ADD USER, EDIT USER pages, it's working as expected.

More details here:

Test Report

Description

I've tested the patch on WordPress Playground, and it's functioning as expected in ADD NEW USER and EDIT USER pages also. ✅

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8223

Environment

• WordPress: 6.8-alpha-20250130.101504
• PHP: 7.4.31-dev
• Server: PHP.wasm
• Database: WP_SQLite_Translator (Server: 5.5 / Client: 3.40.1)
• Browser: Chrome 134.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

ADD NEW USER:

• When Password is Visible:

• When Password is Hidden:

EDIT EXITING USER:

• When Password is Visible:

• When Password is Hidden:

Supplemental Artifacts

Added Inline

[narenin]

Actual Results

✅ Issue resolved with patch.

ADD NEW USER:

When Password is Visible:

When Password is Hidden:

EDIT EXITING USER:

When Password is Visible:

When Password is Hidden:

[audrasjb]

@narenin yes I can confirm the patch works fine on each admin password input.
Question: Should we have a similar implementation for Post Password fields?

[audrasjb]

Answer: not necessary as Post Password field doesn't allow the user to convert it to a text input :)

[vgnavada]

Replying to audrasjb:

Answer: not necessary as Post Password field doesn't allow the user to convert it to a text input :)

Exactly 😀✅

[devsahadat]

Thank you for reporting this issue and for the proposed fix.

I’ve thoroughly reviewed the bug report and analyzed the patch provided in PR #8223. The issue stems from password fields remaining in text mode when a form is submitted, which could lead to unintended password autofill behavior. The proposed fix correctly resets the input type to password upon submission, mitigating this risk.

Testing & Verification

I have tested the patch in the following scenarios:

• Login Page ✅
• Add New User Page ✅
• Edit User Page ✅

In all cases, the password field correctly reverts to password upon form submission. This aligns with best practices, such as those recommended by the UK Government Design System.

[johnbillion]

@narenin May I ask why the screenshots in your test reports are identical to those from @vgnavada?

[SirLouen]

@johnbillion this is a topic we commented about some months ago in a Testing Chat. Basically, the Mr. commented that he thought that copy/pasting reports was a nice way of patch testing confirmation. We explained that this was not the best idea to do, and he got it.

[vgnavada]

Replying to johnbillion:

@narenin May I ask why the screenshots in your test reports are identical to those from @vgnavada?

Yes, @johnbillion, we discussed this in the test team chat, and it was resolved.

Thank you @SirLouen for your response :)

[johnbillion]

I've tested ​PR 8223 and it's working well.

The test reports above were not testing the actual proposed change, which is that when the form is submitted the password input type is reverted to password if it's been toggled to text via the Show button. I've tested this using a breakpoint in the browser and confirmed that the input type and the toggled button get reverted prior to the form being submitted.

I must admit that I was unable to get my browser to remember the plain text password value prior to applying the patch but I suspect it depends on your browser settings for remembering submitted form data. I'm happy to trust the advice from the gov.uk design service on this occasion.

Login screen

User profile screen

New user screen

[johnbillion]

In 60306:

Login and Registration: Ensure a revealed password is reverted to the password input type upon form submission.

This means if a password has been toggled to visible by the user, or is visible by default, it gets reverted to the password type to prevent browsers from remembering it as a previously-provided value and potentially displaying it as an autofill option on non-password inputs.

Props jamieburchell, sukhendu2002, vgnavada

Fixes #62147