Fix autocomplete="off" in Chrome

[azaozz]

Seems latest Chrome doesn't respect autocomplete="off" on <input type="password" /> fields. This is a problem in forms where the user has to choose a password like the Profile and Edit User screens.

When the user wants to change a setting on the Profile screen, the first password field is auto-filled. That results in error on submitting the form: "ERROR: You entered your new password only once...".

[azaozz]

Setting autocomplete="off" on the <form> tag seems to fix this.

[azaozz]

In 24291:

Fix Chrome disregarding autocomplete="off" for password fields. Add autocomplete="off" to forms where the users can choose new password. Fixes #24364.

[SergeyBiryukov]

Could we do this just for Chrome?

I often use autocomplete for Username, E-mail, First Name, Last Name, and Website when creating or editing user accounts.

[johnbillion]

[24291] should never have gone in without a) verifying this is actually a reproducable bug, b) some discussion and c) some testing.

I cannot reproduce this issue on Chrome 26 or Chrome Canary 29 on Win7 or OS X.

I don't think disabling autocomplete on an entire form is an acceptable solution even if it is a bug.

Can anyone else reproduce this? If so, browser/OS details please.

[azaozz]

Replying to johnbillion:

I cannot reproduce this issue on Chrome 26 or Chrome Canary 29 on Win7 or OS X.

Reproduced by couple of people in Chrome 26 on both Win7 and OS X:

• With the default Chrome settings, change your password on the Profile screen.
• Quit the browser, start it again and go to the same screen.
• Some of the fields including the first "New Password" field are auto-filled (yellow background) despite having autocomplete="off".

This depends on what auto-fill data the browser has stored. Here it also fills "Jabber / Google Talk" (with a wrong value) despite that I've never entered anything there.

This looks like yet another recent bug in Chrome. The worst part is that Chrome stores data entered in autocomplete="off" fields. If that is on a public computer, it breaks security.

@SergeyBiryukov perhaps we can add autocomplete="on" for these fields. This should work according to the specs, although probably better not to let the browser store any of the data. These forms are used very rarely by users and a bit more often by admins. Cases where the data is the same are extremely rare, apart from setting test installs.

[aaroncampbell]

I'd like to see if we can get Chrome's take on this. Does anyone have any connections there? I don't like the fix of putting the autocomplete="off" on the whole form. Especially if this is a mistake that Chrome is going to fix in the next release or two.

[nacin]

In 24317:

Revert [24291] pending further discussion and sleuthing. see #24364.

[SergeyBiryukov]

Replying to johnbillion:

Can anyone else reproduce this? If so, browser/OS details please.

I can reproduce in Chrome 27 on Windows XP. Chrome fills in one password field on the Profile screen (despite autocomplete="off"), and also fills in the Jabber / Google Talk field with the username.

Related IRC chat: ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-05-22&sort=asc#m616159

[nacin]

I've reached out to some people.

[azaozz]

Think we can keep the autocomplete="off" on resetpassform in ​wp-login.php. All fields there already have that individually.

[markjaquith]

So we determined that the only way to fix this in Chrome stable is to set autocomplete="off" for the whole form. Seriously annoying. Nacin is reaching out to some Chrome people, but in the meantime, I'm marking this as a blocker.

[markjaquith]

Don't hate me:

<script>
jQuery(function($){
	setTimeout( function(){
		$('input', '#your-profile').each( function(i, v) {
			$v = $(v);
			if ( $v.css('background-color') === 'rgb(250, 255, 189)' ) {
				console.log( $v );
				$v.val('');
			}
		});
		$('#pass1').val('');
	}, 100 );
});
</script>

I've been trying variations on this theme. You have to wait a little bit (100 ms is what I settled on) to let Chrome to its dirty work. And then you can act. Instead of looking at the background color (super janky), we could just do the pass1 one (which I've hardcoded, because we don't want to miss it), or we could to data-original-value="" elements.

None of these options are great, and I may just be adding additional heft to the "just mark the whole form as autocomplete="off" strategy".

[markjaquith]

Aha, there is a selector:

<script>
jQuery(function($){
	setTimeout( function(){
		$('input:-webkit-autofill', '#your-profile').each( function(i, v) {
			$(v).val('');
		});
	}, 100 );
});
</script>

[johnbillion]

If we're going this route, I think we could use Underscore's defer() method to avoid using the hacky timeout.

[azaozz]

Yep, input:-webkit-autofill works. Every time a value is removed we will need to add a class to fix the yellow background (it remains and Chrome prevents overwriting it).

[azaozz]

24364.patch also adds autocomplete="off" on resetpassform in wp-login.php.

[bobbingwide]

I've just finished writing up my analysis of the problem... performed before I found this TRAC.
I developed a more pragmatic solution involving a single space character.

I have discovered that appending a blank to the field before it’s displayed DOES appear to cure the problem.
To achieve this I hacked wp-admin/user-edit.php changing

value="<?php echo esc_attr($profileuser->$name) ?>"

to

value="<?php echo esc_attr($profileuser->$name) ?> "

For details see ​http://herbmiller.me/2013/06/26/pre-populated-new-password-field-is-it-just-me-and-chrome-or-what/

[markjaquith]

bobbingwide — that gave me some further ideas.

1: Make all the form's password fields disabled on page load, then enables them a little bit later.

<script>
jQuery(function($){
	$( 'input[type="password"]:enabled', '#your-profile' ).each(function(k,v) {
		$(v).prop( 'disabled', true );
		setTimeout( function(){ $(v).prop( 'disabled', false ); }, 200 );
	});
});
</script>

2: Set the whole form to autocomplete="off" in the HTML and then:

<script>
jQuery(function($){
	setTimeout( function(){ $('#your-profile').prop('autocomplete', 'on'); }, 500 );
});
</script>

Longer delay here as not having autocomplete available isn't as worrisome as not being able to click the password fields.

[azaozz]

Couple more potential fixes:

• 24364-2.patch​ adds a non-empty hidden text field right before the first password field. This stops Chrome's aggressive autofill (props aaroncampbell).
• 24364-3.patch​ sets the two password fields to disabled before the page has finished loading as suggested by markjaquith above.

[bobbingwide]

markjaquith, azaozz - can we just go back to basics here?
24364-2.patch on its own works fine for me with Chrome Version 27.0.1453.116 m

So why do you still need all the jQuery?

[azaozz]

Replying to bobbingwide:

Yeah, I like the hack in 24364-2 as it doesn't depend on JS. The only problem is that it *might* stop working in future versions of Chrome. Thinking we can take that risk and use it for now, then switch to a JS based hack if Chrome decides to bypass it.

[markjaquith]

Cleaned up and simplified hidden input patch

[markjaquith]

With HTML comments so people don't wonder WTF is going on.

[markjaquith]

Brings back value=" " (blank space) as non-empty values are also checked by Chrome.

[markjaquith]

In 24551:

Rejigger some whitespace in anticipation of a fix for #24364.

see #24364

[markjaquith]

In 24552:

Combat Chrome's insanely aggressive user/pass autofilling ಠ_ಠ

Chrome now ignores autocomplete="off" in <input>, so this hack uses
a hidden, non-named, non-empty input, right before the password field.

see #24364. props azaozz, nacin, bobbingwide, aaroncampbell.

[markjaquith]

In 24553:

Set autocomplete="off" on the password reset form itself, in addition to the individual inputs, to work around a Chrome bug.

fixes #24364. props azaozz.

[sc0ttkclark]

<input class="hidden" value=" " /><!-- #24364 workaround -->

Is the hidden input hack still necessary for Chrome?