Password field has wrongly focus on installations

[zodiac1978]

In the last step of an installation you get asked for a title, username and password, email and visibility (in this order).

But the password field in the middle gets the focus. This is counterintuitive. The first item of the form should get the focus.

Why does this happen?

There is a JS one-liner which should put the focus on the first element of the form:

<script type="text/javascript">
  var t = document.getElementById('weblog_title'); if (t){ t.focus(); }
</script>

But unfortunately the file user-profile.js is called after that and it contains this code:

    function g() {
        "function" != typeof zxcvbn ? setTimeout(g, 50) : (!a.val() || h.hasClass("is-open") ? (a.val(a.data("pw")), a.trigger("pwupdate")) : C(), x(), y(), 1 !== parseInt(r.data("start-masked"), 10) ? a.attr("type", "text") : r.trigger("click"), o("#pw-weak-text-label").text(v("Confirm use of weak password")), "mailserver_pass" !== a.prop("id") && o(a).trigger("focus"))
    }

The trigger("focus") at the end sets the focus on the password field.

One easy fix could be to change the order here:
​https://github.com/WordPress/WordPress/blob/master/wp-admin/install.php#L479-L485

If we put the online fixing the focus below the wp_print_scripts call it should modify it to the correct first item.

Just one question remains: Why should this not happen on mobile? As there is a check ! wp_is_mobile() ...

[audrasjb]

Thanks for the report, moving this to milestone 6.9.

[abcd95]

Hi @zodiac1978,

I can see that the change was introduced in 36176, which reorganized script loading but didn't account for focus management between scripts.

The reordering of scripts didn't work in my testing since user-profile.js uses a setTimeout while waiting for the zxcvbn password library to load.

and I think the !wp_is_mobile() check prevents automatic focus on mobile because it automatically opens the keyboard, which can be disruptive experience.

[abcd95]

I tried this, and it works like a charm -

diff --git a/src/js/_enqueues/admin/user-profile.js b/src/js/_enqueues/admin/user-profile.js
index 2aebe62a91..36d61fee1a 100644
--- a/src/js/_enqueues/admin/user-profile.js
+++ b/src/js/_enqueues/admin/user-profile.js
@@ -57,7 +57,7 @@
 		$( '#pw-weak-text-label' ).text( __( 'Confirm use of weak password' ) );
 
 		// Focus the password field.
-		if ( 'mailserver_pass' !== $pass1.prop('id' ) ) {
+		if ( 'mailserver_pass' !== $pass1.prop('id' ) && !$('#weblog_title').length ) {
 			$( $pass1 ).trigger( 'focus' );
 		}
 	}

Let me know if this tests well :)

[zodiac1978]

Replying to abcd95:

The reordering of scripts didn't work in my testing since user-profile.js uses a setTimeout while waiting for the zxcvbn password library to load.

and I think the !wp_is_mobile() check prevents automatic focus on mobile because it automatically opens the keyboard, which can be disruptive experience.

This both makes sense. Thanks for the explanation. Very much appreciated!

Can you add this code change as a patch?

[abcd95]

Opening up a PR with the patch to check the automated tests.

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

This PR addresses an issue where the password field incorrectly receives focus during WordPress installation instead of the first field (site title).

This change adds a condition to check if we're on the installation page by looking for the #weblog_title element, and if so, prevents the automatic focus on the password field.

Testing:

1. Start a fresh WordPress installation
2. Proceed to the final setup page
3. Verify that the focus is positioned in the site title field (first field)

[joedolson]

I could wish there was some documentation of why wp_is_mobile() was checked there in the first place, but the original commit that added this doesn't mention it in any way in the commit or in the related ticket. I would guess that @abcd95 is correct, that it was because the automatic keyboard was disruptive. I'm not totally convinced that this is a good reason. The more important accessibility concern around autofocusing is whether or not there's any critical information that precedes the autofocused input that a user could miss - in this case, I think that there isn't. The text before the form is largely insignificant.

The lack of a comment at the time it was added means that it's hard to know whether it could have been a tech issue; e.g. unreliable support or behavior on mobile devices in 2013. I believe that in iOS at that time, triggering .focus() on an input did not open the onscreen keyboard, so autofocus would cause problems on mobile because the user would still need to manually remove and add focus to the field to trigger the keyboard.

For the purpose of this ticket, I think we can leave it as it is; I suspect that executing a WordPress installation on mobile is not a common scenario.

Perhaps @johnbillion has some memory of why that was added, as the author of the patch that added it? I'm sure the 12 year old memory will be super fresh. :)

But I think that this patch is good to go as it is; if we want to remove the mobile check, that can go in a separate ticket.

I've tested and confirmed behavior.

[joedolson]

In 60268:

Upgrade/Install: Avoid setting focus on password during install.

On the installation screen, focus was set first to the site title field, then moved to the password field. Autofocus should only ever be moved to the first field of a form, so that screen reader users don't miss important fields.

Fix by checking whether the site title field is present before setting password field focus.

Props zodiac1978, himanshupathak95, abcd95, joedolson.
Fixes #63281.