Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#53974 closed defect (bug) (fixed)

Repeat Password field missing during installation

Reported by: eric3d's profile Eric3D Owned by: peterwilsoncc's profile peterwilsoncc
Milestone: 6.0 Priority: normal
Severity: normal Version: 5.8
Component: Upgrade/Install Keywords: has-patch
Focuses: ui, javascript Cc:


I did a new install of WP 5.8 on my MAMP server.

On the Installation step, after adding site name, username, password and email, I kept getting a "passwords do not match" error. The problem is that only one password field was displayed.

After some research, I temporarily disabled javascript, which allowed me to see the second password field and complete the installation step. So there seems to be a javascript bug preventing the repeat password field from displaying.

MacOS 10.14.6, Safari 14.1.2, MAMP Pro 6.5, Apache 2.4.48, PHP 7.4.21

Attachments (1)

pass2not_updated.png (529.5 KB) - added by mkox 2 years ago.
Safari passwords do not match

Download all attachments as: .zip

Change History (17)

#1 @SergeyBiryukov
3 years ago

  • Component changed from Administration to Upgrade/Install
  • Keywords reporter-feedback added

Hi there, welcome back to WordPress Trac! Thanks for the report.

On the Installation step, after adding site name, username, password and email, I kept getting a "passwords do not match" error. The problem is that only one password field was displayed.

I could not reproduce the issue in my testing (currently using Edge 92.0.902.73).

Looking at the bindPasswordForm() JS function, only one password field is supposed to be displayed, the other one is hidden but synchronized automatically with the first one in case extensions like LastPass fill the second one.

  1. Which browser are you using?
  2. Does the issue still happen with all browser extensions disabled?
  3. Are there any JavaScript errors or warnings in the browser console?
  4. Could you try copying all the files from a freshly downloaded package to make sure they are all in place?

#2 @jrf
2 years ago

@synchro just reported exactly the same issue: with a second person confirming the issue.

#3 @Synchro
2 years ago

As Juliette says, I ran into this when using a password pasted from 1Password. This occurred on a brand-new, untouched 5.9 installation. I'm in Safari 15.2 on macOS 12.1.

I just tried it again and I do see a JS error logged:

[Error] TypeError: undefined is not an object (evaluating '')

(anonymous function) (jquery.min.js:2:31711)

On the same form, the eye button to reveal the password does nothing (and doesn't log any more errors), though this may be an unrelated consequence of that first error.

#4 @michelangelovandam
2 years ago

Hi all,

I ran into this issue since WordPress 5.7 where I replaced the generated password with one I provided myself:

  1. A random 50 character password generated by a password manager
  2. By a weak password, something like "Pass123%"

What happens is that in my second case, the weak password requires additional confirmation only after I pressed submit. In the first case the warning for confirming the password only appears after pressing submit.

I created a short video for the second case because this a common issue when testing in a local environment. See WordPress Missing Password Confirmation video on YouTube at In the video I was using WordPress 5.7.2.

I was able to circumvent the issue by removing the "display: none" class on the password confirmation field.

#5 @jrf
2 years ago

  • Focuses ui added
  • Keywords needs-patch added; reporter-feedback removed
  • Milestone changed from Awaiting Review to 6.0

2 years ago

Safari passwords do not match

This ticket was mentioned in PR #2266 on WordPress/wordpress-develop by walbo.

2 years ago

  • Keywords has-patch added; needs-patch removed

#7 @walbo
2 years ago

Can reproduce the issue in safari.

[Warning] jQuery.Deferred exception: undefined is not an object (evaluating '$') (2) (jquery.js, line 4050)

[Error] TypeError: undefined is not an object (evaluating '$')
	(anonym funksjon) (jquery.js:4059)

In user-profile.js:
The issue seems to be that inside the function bindPass1() the function generatePassword() is runned, but generatePassword requires the $toggleButton to be defined. This doesn't happend before after bindPass1 is runned.

Added a PR to bind the $toggleButton before bindPass1 is runned.

#8 @lkraav
2 years ago

See also #52086, user profiles screen JS indeed seems to suffer from general brittleness.

#9 @afragen
2 years ago

I just tried to replicate this using LocalWP, Apache 2.4.43, PHP 7.3.5, MySQL 8.0.16, and WP 5.9.3, Safari 15.4

I created a site in Local with the above parameters. Used wp db reset --yes --defaults to wipe the database and then entered a weak password. I did not see the password confirmation field, but the user/password was correctly used and I was presented with the confirmation screen and then a login screen.

I even removed the wp-config.php to recreate it during the "5-minute install" and it still worked.

Last edited 2 years ago by afragen (previous) (diff)

#10 @peterwilsoncc
2 years ago

I am able to reproduce this consistently by changing the source of zxcvbn-async to /wp-includes/js/zxcvbn.min.js in the file src/wp-includes/script-loader.php.

This forces the race condition mentioned in comment#11 of #52086. The bug appears to be the same root cause as this one.

I am experimenting with a fix.

#12 @peterwilsoncc
2 years ago

  • Focuses javascript added

I've pushed a pull request that makes the following changes:

  • calls bindToggle() in generatePassword()
  • Ensures the toggle button isn't bound multiple times
  • this is a stopgap solution that will need a follow up ticket to improve the code

It seems to fix both this and the similar issue reported in #52086.

It's best to test by forcing the race condition with the instructions in the previous comment.

#13 @costdev
2 years ago

I've tested PR 2550 by forcing the race condition and it fixes the issue on the install, Add New User and the Edit User screen.

This is certainly a stopgap fix but it allows installation to proceed while further investigation is done to review and improve the login screen/user profile JS in a later ticket.

#14 @peterwilsoncc
2 years ago

@costdev Thanks for testing and for the assistance figuring out how to force the race condition.

I'm leaning toward committing the hacky stopgap solution as allowing users to install, create users and/or change their password all seem important.

#15 @peterwilsoncc
2 years ago

  • Owner set to peterwilsoncc
  • Resolution set to fixed
  • Status changed from new to closed

In 53122:

Upgrade/Install/Users: Prevent JS bug filling new passwords.

A JavaScript race condition was throwing an error and preventing passwords from being set if the zxcvbn library loaded earlier than expected. This could prevent the installation of WordPress or the creation/updating of user accounts.

Props adi64bit, afragen, agepcom, audrasjb, bedas, brookedot, cbigler, charlyox, costdev, desrosj, drago239, Eric3D, espiat, jadpm, jrf, justinahinon, kubiq, lkraav, michelangelovandam, mirkolofio, mkox, peterwilsoncc, poena, sbossarte, sebastienserre, SergeyBiryukov, Synchro, thomasplevy, walbo, waterfire, wpmakenorg.
Fixes #53974, #52086.

Note: See TracTickets for help on using tickets.