WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 8 months ago

#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:

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 3 years ago.
24364-2.patch (2.0 KB) - added by azaozz 3 years ago.
24364-3.patch (400 bytes) - added by azaozz 3 years ago.
24364.diff (727 bytes) - added by markjaquith 3 years ago.
24364.2.diff (1.6 KB) - added by markjaquith 3 years ago.
Cleaned up and simplified hidden input patch
24364.3.diff (1.7 KB) - added by markjaquith 3 years ago.
With HTML comments so people don't wonder WTF is going on.
24364.4.diff (1.7 KB) - added by markjaquith 3 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
3 years ago

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

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

Version 2, edited 3 years ago by azaozz (previous) (next) (diff)

#6 @aaroncampbell
3 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
3 years ago

In 24317:

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

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

I've reached out to some people.

#10 @ocean90
3 years ago

  • Cc ocean90 added

#11 @azaozz
3 years ago

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

#12 @markjaquith
3 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
3 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
3 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
3 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 3 years ago by johnbillion (previous) (diff)

#16 @azaozz
3 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
3 years ago

#17 @azaozz
3 years ago

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

#18 @bobbingwide
3 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
3 years ago

  • Cc herb@… added

#20 @markjaquith
3 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
3 years ago

@azaozz
3 years ago

@markjaquith
3 years ago

#21 @azaozz
3 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
3 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
3 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
3 years ago

Cleaned up and simplified hidden input patch

@markjaquith
3 years ago

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

@markjaquith
3 years ago

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

#24 @markjaquith
3 years ago

In 24551:

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

see #24364

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


8 months ago

#28 @sc0ttkclark
8 months ago

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

Is the hidden input hack still necessary for Chrome?

Note: See TracTickets for help on using tickets.