On installation page, autocompleted password should not be visible.

[smerriman]

We have a development server where new installations of WordPress are regularly created on the same domain.

On the WP installation page, if you enter a username used elsewhere on the domain, the password field will be autocompleted if you have set the browser to remember it.

The fact the autocomplete occurs is not a problem - however, the password appears in plain text. If anybody else is watching the screen, seeing a brand new random password for a brand new installation is OK (and you can click hide and change it if necessary) - but seeing a saved password from elsewhere is not.

Autocompleted passwords should never appear in plain text. Removing autocomplete is one option, though some people may find it useful - but I think the ideal solution is that any changes to the password field should hide it automatically.

[bookdude13]

Hey @smerriman, sorry for the late reply on this! I can confirm that this is still happening in trunk (~5.4) on Chrome. I agree with you, an auto-filled password should be hidden if possible. since there's usually no reason to view it. I can look into this more in the next few days.

[bookdude13]

Hide password if autocomplete detected

[bookdude13]

I added a patch. When Chrome does the autofill a change event is fired. I'm checking if that event happens within the first 200ms, then toggling the 'hide' button. Tested on my version of Chrome (79.0.3945.130), not tested on other browsers or mobile.

[xkon]

I'm on Chrome 79.0.3945.130 as well but I can't even replicate this 😅 not sure if I'm missing anything here. I'm not getting any actual "autofill" unless I select it on my own from the dropdown that appears when going at the Username field. If this is the case then personally I don't count this as autofill as it's a user-driven action.

Also, Chrome is known in general to have issues with autocomplete=off and there are ways devised to bypass this hiccup but none are solid IMO.

I suggest to reverse the way Show/Hide works here and always have the password hidden by default as that's the usual flow seen throughout websites even if it's pre-filled or filled by users.

It's then up to the user to press the "Show" button if they feel it's safe enough to view/copy their password.

[bookdude13]

Replication steps I used:

• Allow Chrome to ask to save passwords (in chrome://settings)
• Create new WP database, do fresh install
• Save user credentials when prompted
• Delete database, recreate w/ same name/user
• Go to install page using same tab, start process again
• The email and password fields should autofill

I agree that there is no good workaround for Chrome autocomplete, after looking into it (and past WP tickets) for a while. I'm fine having it auto-hidden. The only issue I can see is if there's confusion between Chrome's autofill password being used or an autogenerated one. That would be a separate ticket though, and I believe isn't an issue right now. I can make a patch to change the default to hide.

[bookdude13]

Hide password by default

[bookdude13]

Changed the hide/show button to always start as a masked password. Updated the initial button text to reflect this. Works in my Chrome install and in Firefox 72.0.2.

However, in Firefox the autofilled password doesn't actually autofill the password field, so the password is set to a newly generated password and is hidden so the user doesn't see this issue. The background still changes color though. That might be worthy of a separate ticket.

[bookdude13]

Looking into this further, the original ​Plan for Passwords had the objective of keeping passwords visible in plain text. Patch 35707.2 would go directly against that. However, the login form in wp-login.php line 1364 sets the input field to type="password" initially as well, so that might be a moot point.

Further, the patch 35707.2 is not working for me anymore, since Chrome's autofill makes the password visible even if it would normally be hidden. If autofill isn't enabled then the password would start hidden with the patch, the opposite of what makes sense. And the password field on the install page should normally be type="text" to show the generated password when autofill isn't used.

Patch 35707.1 would work for now, but needs some sort of ​polyfill for it to function on other browsers (currently not working on Firefox).

The question to advance this ticket: should we use an approach like 35707.1 with a polyfill, or should we not deal with this?
@smerriman is this still an issue for you, or have you found a workaround for your case?