Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 9 years ago

#24364 closed defect (bug) (fixed)

Fix autocomplete="off" in Chrome

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

Description

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

Download all attachments as: .zip

Change History (35)

#1 @azaozz
12 years ago

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

#2 @azaozz
12 years 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.

#3 @SergeyBiryukov
12 years 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.

#4 follow-ups: @johnbillion
12 years 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.

#5 in reply to: ↑ 4 @azaozz
12 years 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 12 years ago by azaozz (previous) (diff)

#6 @aaroncampbell
12 years 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.

#7 @nacin
12 years ago

In 24317:

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

#8 in reply to: ↑ 4 @SergeyBiryukov
12 years 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

#9 @nacin
12 years ago

I've reached out to some people.

#10 @ocean90
12 years ago

  • Cc ocean90 added

#11 @azaozz
12 years ago

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

#12 @markjaquith
11 years 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.

#13 @markjaquith
11 years ago

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

#14 @markjaquith
11 years ago

Aha, there is a selector:

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

#15 @johnbillion
11 years ago

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

Last edited 11 years ago by johnbillion (previous) (diff)

#16 @azaozz
11 years 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).

@azaozz
11 years ago

#17 @azaozz
11 years ago

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

#18 @bobbingwide
11 years 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) ?>"

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/

#19 @bobbingwide
11 years ago

  • Cc herb@… added

#20 @markjaquith
11 years 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.

<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
11 years ago

@azaozz
11 years ago

@markjaquith
11 years ago

#21 @azaozz
11 years 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.

#22 follow-up: @bobbingwide
11 years 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?


#23 in reply to: ↑ 22 @azaozz
11 years 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.

@markjaquith
11 years ago

Cleaned up and simplified hidden input patch

@markjaquith
11 years ago

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

@markjaquith
11 years ago

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

#24 @markjaquith
11 years ago

In 24551:

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

see #24364

#25 @markjaquith
11 years 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.

#26 @markjaquith
11 years 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.

This ticket was mentioned in Slack in #core-fields by sc0ttkclark. View the logs.


9 years ago

#28 @sc0ttkclark
9 years ago

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

Is the hidden input hack still necessary for Chrome?

Note: See TracTickets for help on using tickets.