Users: Only set initial focus on the password field on the reset password form

[i-am-chitti]

Ticket

https://core.trac.wordpress.org/ticket/65630

Description

Setting initial focus on a specific control only makes sense when there is a single, well-defined task for the user. On the Add New User screen, focus is currently placed on the password field in the middle of the form, skipping the Username, Email, and Name fields. This disrupts the native tab order and hurts discoverability for keyboard and screen reader users.

Cause

In src/js/_enqueues/admin/user-profile.js, the password field is focused whenever generatePassword() runs, which happens on every screen where the field carries data-reveal="1" — the wp-login.php reset password form, install.php, and user-new.php (Add New User).

The existing guard is a blocklist that only excludes the mailserver (#mailserver_pass) and install (#weblog_title) screens, so Add New User slips through and steals focus. The behavior was originally introduced in 52193 and was only ever intended for the reset password field on wp-login.php; the shared selector caused it to leak onto other pages.

Testing

• Add New User (wp-admin/user-new.php): focus is no longer forced onto the password field; tab order starts at the top of the form.
• Reset password (wp-login.php): password field still receives focus as intended.
• Unaffected screens verified: install.php, options-writing.php (#mailserver_pass), setup-config.php (#pwd, not matched by $pass1).

Screenshots

Before

Screen.Recording.2026-07-15.at.12.14.49.PM.mov

After

Screen.Recording.2026-07-15.at.12.14.06.PM.mov

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props iamchitti, afercia.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[afercia]

@i-am-chitti thanks for your PR. While testing, I noticed something I was not aware of.

Can you please help me confirm the following:

• Completely remove the line that sets focus on the password field.
• Follow the reset password flow from the login screen. This implies setting up the environment to catch emails with Mailpit and get the link to the reset password screen.
• On the reset password screen, observe the password field gets initial focus anyways even after the code in user-profile.js is removed.

To my understanding, in wp-login.php the case 'rp': of the big PHP switch prints out the markup for the reset password screen. It already includes a small JS script to set focus when the password input field is not empty, which is always the case.

See here:

wordpress-develop/src/wp-login.php

Lines 426 to 435 in 144d701

	if ( ! empty( $input_id ) ) {
	ob_start();
	?>
	<script>
	try{document.getElementById('<?php echo $input_id; ?>').focus();}catch(e){}
	if(typeof wpOnload==='function')wpOnload();
	</script>
	<?php
	wp_print_inline_script_tag( wp_remove_surrounding_empty_script_tags( ob_get_clean() ) );
	}

If it is confirmed, I wonder why the code in user-profile.js was added in the first place as it appears the original intent was scoped to the reset password screen, which already sets focus on the password field.

[i-am-chitti]

Thanks @afercia for pointing out. I traced it through all three changesets and this JS line has been redundant since it was added.

52193 added it alongside the real fix: correcting login_footer( 'user_pass' ) → login_footer( 'pass1' ), which prints the server-side inline script that focuses #pass1. Since user-profile.js is enqueued on the reset screen too

wordpress-develop/src/wp-login.php

Line 1092 in 144d701

login_footer( 'pass1' );

, the JS trigger( 'focus' ) just repeats focus the inline script already set. And because $pass1 matches #pass1 / #mailserver_pass on multiple screens, it leaks focus elsewhere.

The follow-ups confirm it: 55974 and 60268 each added a guard (mailserver_pass, then #weblog_title) to stop that leak on new pages. 65630 is just the next instance.

Is explicit focus required? No — the reset screen keeps its focus via login_footer( 'pass1' ). Verified manually - reset screen still has focus.

Regressions from removing it? None. Reset password still works; Add New User / install / options-writing have no focus on password field as desired. Hence, I've dropped the block entirely.

[afercia]

@i-am-chitti Thank you for the thorough investigation 👍🏻

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 62764
GitHub commit: 7a4fd81

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.