Make WordPress Core

Opened 7 years ago

Closed 3 years ago

Last modified 3 years ago

#40275 closed enhancement (fixed)

Use a monospace-type font to display passwords

Reported by: robdxw's profile robdxw Owned by: ryelle's profile ryelle
Milestone: 5.8 Priority: normal
Severity: normal Version: 5.8
Component: Users Keywords: good-first-bug needs-patch
Focuses: ui, css Cc:


There are a number of places where passwords are echoed back to users e.g. in wp-activate.php when a user activates their account, or when a password is suggested when a user first registers.

Because these fields are generally displayed in Helvetica Neue or Arial, there is the potential for character confusion if a user transcribes their password, rather than copy-and-pasting. This would be eliminated by using a monospace-type font to display the password.

E.g. compare




Attachments (4)

Screen Shot 2017-03-27 at 14.47.23.png (38.1 KB) - added by robdxw 7 years ago.
Example on user profile age.
40275.diff (390 bytes) - added by utz119 4 years ago.
40275.png (50.2 KB) - added by utz119 4 years ago.
The monospace font has been added to the password field.
40275.1.diff (416 bytes) - added by Hareesh Pillai 3 years ago.
Patch updated against trunk

Download all attachments as: .zip

Change History (15)

7 years ago

Example on user profile age.

#1 @sabernhardt
4 years ago

  • Focuses ui css added
  • Keywords needs-design-feedback added
  • Version 4.8 deleted

This ticket was mentioned in Slack in #core by noisysocks. View the logs.

4 years ago

#3 @kirasong
4 years ago

  • Keywords good-first-bug added
  • Milestone changed from Awaiting Review to Future Release

Sorry for the very slow response on this ticket!

It was brought up in triage today, and I think it's a great idea -- this seemed to be consensus in the meeting as well.

Moving it to Future Release, and adding good-first-bug so that it gets a bit more visibility from folks.

#4 @SergeyBiryukov
4 years ago

  • Component changed from General to Users

4 years ago

4 years ago

The monospace font has been added to the password field.

#5 @utz119
4 years ago

  • Keywords has-patch added

#6 @hedgefield
4 years ago

  • Keywords needs-design-feedback removed

Looks good! Thanks for making a patch, good suggestion. What needs to be done here to ship this?

@Hareesh Pillai
3 years ago

Patch updated against trunk

#7 @Hareesh Pillai
3 years ago

  • Milestone changed from Future Release to 5.8

This ticket has design feedback and an updated patch.
Adding it to the upcoming milestone.

#8 @ryelle
3 years ago

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

In 50846:

Login, Users: Use a monospace font to display passwords.

When typing a password, the input field should use a monospace font. It's easier to distinguish letters in monospace fonts, which makes it easier to accurately read passwords.

Props robdxw, utz119, hedgefield, hareesh-pillai.
Fixes #40275.

#9 @pixolin
3 years ago

  • Keywords needs-patch added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version set to trunk

While I agree, formatting the password input field with a monospace font makes it by far more readable, I believe it would be easier to add the existing class code to the input-field in file (line 637)

<input type="password" name="pass1" id="pass1" class="regular-text code" value="" autocomplete="off" data-pw="<?php echo esc_attr( wp_generate_password( 24 ) ); ?>" aria-describedby="pass-strength-result" />

and in (line 567):

<input type="password" name="pass1" id="pass1" class="regular-text code" autocomplete="off" data-reveal="1" data-pw="<?php echo esc_attr( $initial_password ); ?>" aria-describedby="pass-strength-result" />

The class .code was already defined in file (line 53).

Certainly not a big difference, but redeclaring a css rule seems redundant to me.

(Sorry for not providing a patch. Haven't done that since ages and feel somewhat clueless if it comes to SVN.)

#10 @desrosj
3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

I'm going to close this out again as we're just about ready to package 5.8 RC1 and this would be a relatively minor change that is not a blocker for that to happen.

If a committer feels like this should be addressed prior to 5.8's release, they can reopen and make the change. If there's more sentiment that the new suggestion should be applied, but it can wait for 5.8.1 or 5.9, let's open a new ticket.

#11 @pixolin
3 years ago

Honestly, I wasn't even sure if reopening the ticket was the right thing to do. Since my objection here is a banality, I fully understand that it is not being given priority. Perhaps it can be accommodated in a future release.

Thank you for your kind attention.

Note: See TracTickets for help on using tickets.