Make WordPress Core

#24364 closed defect (bug) (fixed)

Fix autocomplete="off" in Chrome

Reported by: azaozz Owned by: azaozz
Milestone: 3.6 Priority: normal
Severity: blocker Version:
Component: Administration Keywords:
Focuses: Cc:


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...".

Attachments (7)

24364.patch (2.0 KB) - added by azaozz 10 months ago.
24364-2.patch (2.0 KB) - added by azaozz 10 months ago.
24364-3.patch (400 bytes) - added by azaozz 10 months ago.
24364.diff (727 bytes) - added by markjaquith 10 months ago.
24364.2.diff (1.6 KB) - added by markjaquith 10 months ago.
Cleaned up and simplified hidden input patch
24364.3.diff (1.7 KB) - added by markjaquith 10 months ago.
With HTML comments so people don't wonder WTF is going on.
24364.4.diff (1.7 KB) - added by markjaquith 10 months ago.
Brings back value=" " (blank space) as non-empty values are also checked by Chrome.

Download all attachments as: .zip

Change History (33)

comment:1 azaozz11 months ago

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

comment:2 azaozz11 months ago

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

In 24291:

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

comment:3 SergeyBiryukov11 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:4 follow-ups: johnbillion11 months ago

[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.

comment:5 in reply to: ↑ 4 azaozz11 months ago

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.

Last edited 11 months ago by azaozz (previous) (diff)

comment:6 aaroncampbell11 months ago

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.

comment:7 nacin11 months ago

In 24317:

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

comment:8 in reply to: ↑ 4 SergeyBiryukov11 months ago

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

comment:9 nacin11 months ago

I've reached out to some people.

comment:10 ocean9011 months ago

  • Cc ocean90 added

comment:11 azaozz11 months ago

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

comment:12 markjaquith10 months ago

  • Severity changed from normal to blocker

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.

comment:13 markjaquith10 months ago

Don't hate me:

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

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".

comment:14 markjaquith10 months ago

Aha, there is a selector:

	setTimeout( function(){
		$('input:-webkit-autofill', '#your-profile').each( function(i, v) {
	}, 100 );

comment:15 johnbillion10 months ago

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

Last edited 10 months ago by johnbillion (previous) (diff)

comment:16 azaozz10 months ago

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).

azaozz10 months ago

comment:17 azaozz10 months ago

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

comment:18 bobbingwide10 months ago

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) ?>"


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/

comment:19 bobbingwide10 months ago

  • Cc herb@… added

comment:20 markjaquith10 months ago

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.

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

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

	setTimeout( function(){ $('#your-profile').prop('autocomplete', 'on'); }, 500 );

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

azaozz10 months ago

azaozz10 months ago

markjaquith10 months ago

comment:21 azaozz10 months ago

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.

comment:22 follow-up: bobbingwide10 months ago

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?

comment:23 in reply to: ↑ 22 azaozz10 months ago

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.

markjaquith10 months ago

Cleaned up and simplified hidden input patch

markjaquith10 months ago

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

markjaquith10 months ago

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

comment:24 markjaquith10 months ago

In 24551:

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

see #24364

comment:25 markjaquith10 months ago

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.

comment:26 markjaquith10 months ago

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

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.

Note: See TracTickets for help on using tickets.