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

[afercia]

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.

[afercia]

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

[afercia]

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 preserver, 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

[afercia]

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

[adamsilverstein]

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.

[afercia]

Screenshot:

• 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

[pento]

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.

[afercia]

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

[pento]

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

[desrosj]

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

[bookdude13]

Refreshed patch

[bookdude13]

Patch refreshed. A few suggestions to improve (needs design review):

• When editing a user (or your own profile) the "Set New Password" button text could change to "Generate New Password" once the field appears.
• When editing a user (or your own profile) the "Cancel" button could hide all of the fields, making the "Set New Password" button act as a toggle for their appearance
• There is not a way to generate new strong passwords during installation
• It should be checked that #42853 didn't get reverted in this. The code that was changed from there were removed from the original patch here.
• Related: #42766

[bookdude13]

My last refresh was more focused on code porting than functionality...so here's another attempt :)

• This should match the four bullets mentioned by @afercia
• For creating new users, changed it so the fields are never hidden. This also allows for a value to always be set and visible for the password when creating users. Since it's always visible I have the text set to "Generate New Password"
• It still needs to be tested that passwords can't be set even if they were never visible, e.g. an edit profile/user page updating the password by accident when something else updates
• I have not tested on other browsers or mobile, just Chrome.

This still needs design review for the question of how to handle the Cancel button and where to put the Set New Password button (above or below)

Replying to bookdude13:

Patch refreshed. A few suggestions to improve (needs design review):

• When editing a user (or your own profile) the "Set New Password" button text could change to "Generate New Password" once the field appears.
• When editing a user (or your own profile) the "Cancel" button could hide all of the fields, making the "Set New Password" button act as a toggle for their appearance
• There is not a way to generate new strong passwords during installation
• It should be checked that #42853 didn't get reverted in this. The code that was changed from there were removed from the original patch here.
• Related: #42766

[bookdude13]

A cleaner refresh

[adamsilverstein]

Thanks for the patch @bookdude13 - this looks pretty nice, however I feel like somehow this lost some of the original intent of "Cancel" which was to close the "Show Password" section. I think a design review would be worthwhile given how much changed here.

I captured a screencast of how this looks after your patch.

---

@afercia is the issue you described still happening? When I tried to reproduce the field was not cleared when I clicked cancel. If you can still reproduce, what browser/version are you using? Screencast:

---

In the mean time since this needs design review and we are approaching 5.4 beta 3, I'm punting this to 5.5.

[bookdude13]

@adamsilverstein sounds good to punt it out.

I would be fine having the Cancel button close everything up again. Updated patch added to see what that functionality would look like. That latest patch also caches the generated random password value like it used to be, so it doesn't have a delay before showing up. Awaiting design.

Another question when this gets checked: why is there a Cancel button when creating a new user? A password needs to be set, so that seems unintuitive. I'd think it should be like the install page, where you can generate again but can't "cancel" anything.

[bookdude13]

Hiding again, and cached password gen

[michaelarestad]

There are two flows here:

For the "New Password" flow, I think what is proposed makes sense.

For the "New user" flow, I would suggest showing this:

This would remove the buttons to display the password and the cancel button.

As for the "Generate" button, I don't think that's necessary. I don't know how many folks are opinionated about their generated random string. If so, they can customize it.

What do you think?

[whyisjake]

Looks like there is some more work needed here ahead of the 5.5 release. Going to punt to 5.6.

[adamsilverstein]

@michaelarestad thanks for the feedback!

As for the "Generate" button, I don't think that's necessary. I don't know how many folks are opinionated about their generated random string. If so, they can customize it.

What do you think?

That seems fine to me and simplifies the UI. Any problems with removing the from an a11y standpoint @afercia ?

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

[afercia]

Replying to adamsilverstein:

Any problems with removing the from an a11y standpoint @afercia ?

From an a11y perspective, this would be a drastic simplification of the flow to set a new password to it would be an improvement.

However, I'm not sure removing the UI to generate the password would be in line with the original purpose of this feature: encouraging the use of strong passwords. I'd suggest to carefully read the reasoning behind the introduction of this feature in the related ticket #32589 and, more importantly, read the related post on Make:

The Plan for Passwords
​https://make.wordpress.org/core/2015/05/11/the-plan-for-passwords/

[adamsilverstein]

@afercia Ah yes, I remember that ticket. Thanks for reminding me to review the comments there.

I now see why we need to leave the Generate Password button - if the user deletes the password, they have no way to generate a new one. (See https://core.trac.wordpress.org/ticket/32589#comment:20).

[adamsilverstein]

New user:

Edit user:

One more place to check the form works as expected: the initial WordPress setup screen (fresh install). We should also make sure to carefully test this change in our ​supported browsers.

[adamsilverstein]

Setup looks unchanged, password is generated. If I clear the password I have to refresh to get a new one.

[adamsilverstein]

Verified this works well in ie 11, going to commit this.

[adamsilverstein]

In 49248:

Users: improve password generation feature.

On the user edit screen improve handling and clarify language: rename the "Generate Password" and "Show password" buttons to "Set New Password". Clicking it always generates a password. Also: improve inline code comments and descriptions.

Props afercia, bookdude13, michaelarestad, pento.
Fixes #42852.

[adamsilverstein]

In 49251:

Coding Standards: Fix WPCS issues in [49248].

See #42852.

[SergeyBiryukov]

The aria-label attribute for the "Cancel" button was changed from "Cancel password change" to just "Cancel", which duplicates the button text. That doesn't seem right, I think aria-label is supposed to be more descriptive.

Merged into WP Core In https://core.trac.wordpress.org/changeset/49248

[adamsilverstein]

The aria-label attribute for the "Cancel" button was changed from "Cancel password change" to just "Cancel", which duplicates the button text. That doesn't seem right, I think aria-label is supposed to be more descriptive.

I'll fix that, thanks for the feedback.

[adamsilverstein]

@SergeyBiryukov aria fix in 42852.7.diff​

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

[adamsilverstein]

In 49392:

Users: Password generation - restore "Cancel" aria label after r49248.

Restore the "Cancel" button aria label to "Cancel password change" after it was inadvertently changed in r49248.

Props SergeyBiryukov.
Fixes #42852.

Trac ticket closed with https://core.trac.wordpress.org/changeset/49248

Trac ticket closed with https://core.trac.wordpress.org/changeset/49248

[desrosj]

#42749 was marked as a duplicate.