Make WordPress Core

Opened 2 years ago

Last modified 3 months ago

#42852 new defect (bug)

Add new user: new password not generated when reopening Show Password

Reported by: afercia Owned by:
Milestone: 5.4 Priority: normal
Severity: normal Version: 4.7
Component: Users Keywords: has-patch has-screenshots needs-design
Focuses: javascript Cc:
PR Number:


Noticed while working on #42749: After [38494], see also [34312], [33766], [33079], and [32589], in the "Add new user" screen a new password is not displayed when clicking "Show Password", then "Cancel", then "Show Password" again.

In WordPress 4.6:

  • go in the "Add new user" screen (user-new.php)
  • click "Show Password"
  • observe the generated password
  • click "Cancel": the form closes
  • click "Show Password" again
  • observe there's a new generated password displayed

This matched the behavior in the "Your profile" screen (profile.php.)

Repeat the above steps in WordPress 4.7 or more recent version:

  • go in the "Add new user" screen (user-new.php)
  • click "Show Password"
  • observe the generated password
  • click "Cancel": the form closes
  • click "Show Password" again
  • the password field is empty

At this point, there's no way to generate a new password other than reloading the page. Additionally:

  • a real password is actually generated but is not displayed in its "non-masked" form
  • the password field looks empty but the strength indicator says "Strong"
  • clicking "Hide" shows the real password field filled with dots: confusing for users, since the other field is empty

Following the argumentations on the related tickets #33419 and #37902, the implemented changes make sense. However, there's an unintended consequence: the real password field $pass1 is filled up while its visual representation $pass1Text is empty.

Attachments (2)

42852.diff (13.2 KB) - added by afercia 2 years ago.
42852.2.diff (13.2 KB) - added by pento 12 months ago.

Download all attachments as: .zip

Change History (14)

#1 @afercia
2 years ago

See also #32979, with some feedback about the potentially confusing UI.

#2 @afercia
2 years ago

I think the root cause of the problem is some ambiguity in the controls names, as pointed out in #32979, together with the intent to automate some behaviors in a smart way. Sometimes trying to be smart can be confusing for users, as it often assumes one specific workflow while users might have a different intent.

Any change to this UI should try to respect the original intent of the feature, see The Plan for Passwords. Also, the ability for users to generate new passwords added in #33450 should be preserved, but I think it shouldn't happen when clicking "Cancel".

I'd propose to try to keep things simple, and make the UI more transparent to users.

  • rename the "Generate Password" and "Show password" buttons to "Set New Password"
  • make the button always generate a new password each time it gets pressed: the new button text will indicate exactly what the button does (apart from opening the form)
  • don't move focus or select the password programmatically: this is often based on an assumption on a specific workflow and might not be what users want, not to mention is confusing for assistive technologies users
  • make the "Cancel" button just... "Cancel" :) keeping the form open and just clearing the fields would make very clear to users what's going on

/cc @markjaquith @helen @adamsilverstein @SergeyBiryukov

Last edited 12 months ago by afercia (previous) (diff)

2 years ago

#3 @afercia
2 years ago

  • Keywords has-patch added; needs-patch removed

42852.diff is a first try and incorporates accessibility enhancements from #42749 props to @alexstine.

Last edited 12 months ago by afercia (previous) (diff)

#4 @adamsilverstein
2 years ago

  • Keywords needs-screenshots added

Thanks for opening this ticket @afercia - I agree the user experience could greatly improved here and changing the wording is definitely part of that. I'll give your patch a test soon and try to provide some feedback.

At some point on a separate ticket, it would great to consider refactoring the JavaScript which is over complicated by needing to support IE8 which considers the input field type read only.

#5 @afercia
2 years ago

  • Keywords has-screenshots added; needs-screenshots removed



  • clicking "Set New Password" always generates a new password
  • clicking "Cancel" empties the fields; the form stays open, as closing it seems to be one of the root causes of some confusion for users

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

2 years ago

#7 @johnbillion
16 months ago

  • Milestone changed from 5.0 to 5.1

12 months ago

#8 @pento
12 months ago

  • Keywords needs-design added

42852.2.diff refreshes the patch to apply cleanly to trunk.

Having the password field just be blanked by the Cancel button feels kind of weird. It doesn't really give an indication of what that means for the password that this new account will have.

Perhaps it needs some inline help text to explain what the options are for setting a password? Tagging design for their thoughts.

#9 @afercia
12 months ago

If / when committing this change please don't forget props to @alexstine who originally proposed some of these changes in #42749.

#10 @pento
12 months ago

  • Milestone changed from 5.1 to 5.2

Moving to 5.2, as this needs design feedback, and patch updates based on that.

#11 @desrosj
10 months ago

  • Milestone changed from 5.2 to Future Release

This has not been touched since being punted to 5.3, and still needs design. Moving to future-release.

#12 @adamsilverstein
3 months ago

  • Milestone changed from Future Release to 5.4
Note: See TracTickets for help on using tickets.