#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)
Change History (35)
#2
@
12 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 24291:
#3
@
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:
↓ 5
↓ 8
@
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
@
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.
#6
@
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.
#8
in reply to:
↑ 4
@
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
#11
@
12 years ago
Think we can keep the autocomplete="off" on resetpassform in wp-login.php. All fields there already have that individually.
#12
@
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
@
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
@
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
@
11 years ago
If we're going this route, I think we could use Underscore's defer()
method to avoid using the hacky timeout.
#16
@
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).
#18
@
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/
#20
@
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.
#21
@
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:
↓ 23
@
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
@
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.
Setting
autocomplete="off"
on the <form> tag seems to fix this.