WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#5006 closed defect (bug) (fixed)

User profile autofills password

Reported by: braindrain0000 Owned by: westi
Milestone: 2.7 Priority: normal
Severity: normal Version: 2.3
Component: Administration Keywords:
Focuses: Cc:
PR Number:

Description

Using 2.3 RC1. When I try to edit my user profile, the page automatically supplies the user password in the first password field, requiring me to either type it in the second field or clear it from the first in order to make a change to my profile.

Attachments (1)

5006.patch (371 bytes) - added by ninjaWR 11 years ago.
patch containg mrmist's fix

Download all attachments as: .zip

Change History (23)

#1 @braindrain0000
12 years ago

  • Keywords password profile user admin removed

#2 @Viper007Bond
12 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

Works fine for me.

<fieldset id="update-password">
<legend>Update Your Password</legend>
<p class="desc">If you would like to change your password type a new one twice below. Otherwise leave this blank.</p>
<p><label>New Password:<br />
<input type="password" name="pass1" id="pass1" size="16" value="" />

</label></p>
<p><label>Type it one more time:<br />
<input type="password" name="pass2" id="pass2" size="16" value="" />
</label></p>
</fieldset>

You sure it just isn't your browser auto-filling in your password? ;)

#3 @foolswisdom
12 years ago

My guess is your browser is autofilling the first password field, and that is causing the erroneous experience. Maybe, you accidently clicked save password when you changed the password.

#4 @markjaquith
12 years ago

  • Milestone set to 2.4
  • Resolution worksforme deleted
  • Status changed from closed to reopened

We should disable this with autocomplete="off" for those password fields.

#5 @Viper007Bond
12 years ago

Do it via JS as to not break XHTML validation.

#6 @westi
12 years ago

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

(In [7318]) Set autocomplete off for password files on the profile pages. Fixes #5006.

#7 follow-up: @BoltClock
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'd like to reopen this because Firefox 3.0b5pre ignores the autocomplete attribute and goes on to autofill the password field.

#8 in reply to: ↑ 7 @westi
12 years ago

  • Keywords reporter-feedback added
  • Owner changed from anonymous to westi
  • Status changed from reopened to new

Replying to BoltClock:

I'd like to reopen this because Firefox 3.0b5pre ignores the autocomplete attribute and goes on to autofill the password field.

Is there an attribute/method to disable this for FF3 that we can use?

#9 @lloydbudd
12 years ago

BoltClock, is that a recent change in behavior in Firefox? Is there a bug report that corresponds to why this changed? (intentional?) And as westi asks, what is the recommendation from Mozilla?

#10 @BoltClock
12 years ago

  • Keywords reporter-feedback removed

Yes, it seems to be a recent change. For what it's worth, I'm using the latest nightly (2008.03.16 05).

After a little more testing, Firefox seems like it's starting to handle autocomplete="off" quite inconsistently. As I reported, when I try this WP bug fix in Firefox 2, it obeys the attribute, but Firefox 3 doesn't.

However, the bug report at https://bugzilla.mozilla.org/show_bug.cgi?id=362576 has an attachment that I tested with, and both versions disregard the attribute altogether. Both versions also fail to obey the attribute when I devise my own test case.

I'm thinking it might have something to do with JavaScript or, even more specifically, jQuery, since that's what the fix that was committed does.

#11 @BoltClock
12 years ago

Hang on, I missed that that was a really old bug report... nevertheless, Firefox 2 and 3 both display inconsistencies in handling autocomplete="off" from the tests I've conducted. I will continue experimenting and post what happens.

#12 @matt
12 years ago

I think the fix here is to change the "name" attribute of the field to be something unique, like resetpass1 and resetpass2.

#13 @ninjaWR
11 years ago

From #7362 (text not mine)

If you forget to [remove the prepopulated password field], none of the valid changes will be saved because it gives a "passwords don't match" error. In my opinion, it should save the profile changes no matter if the passwords match or not. S If the passwords don't match, save all the other data, leaving the password the same, and say "Changes saved, but the password wasn't updated."

Could this be used as a solution?

#14 follow-up: @mrmist
11 years ago

Still not convinced that this is something that should be being fixed. It's specifically a FF bug because FF is not obeying the autocomplete=off directives. It's an interesting path to go down to attempt to code around all the possible browser eccentricities. [7318] is the actual fix.

FWIW, I tested with unique names as matt mentioned, and that makes no difference.

Anyway, if you actually want a fix, you could just go with


jQuery('#pass1').val('');

Which then forces FF to clear the box.

Sorry, I do not know how to make .diff files. Insert that line into line 64 after

jQuery('#pass1,#pass2').attr('autocomplete','off');


@ninjaWR
11 years ago

patch containg mrmist's fix

#15 @Otto42
11 years ago

The autocomplete=off thing is actually only treated properly by IE. Firefox 2 treated it more like a suggestion, and FF 3 seems to ignore it completely.

But this should work. Clears all password inputs immediately after the page loads.

jQuery(document).ready(function() {
   jQuery('input:password').val('');
});

#16 @mrmist
11 years ago

  • Keywords has-patch added

#17 in reply to: ↑ 14 ; follow-up: @fitztrev
11 years ago

Replying to mrmist:

jQuery('#pass1').val('');

This patch isn't working. The Firefox autocomplete is also filling in the "Jabber/Google Talk" screen name with the username for the blog. Once you tab out of that input field, the autocomplete trumps this line of code and fills in the password.

#18 in reply to: ↑ 17 @mrmist
11 years ago

Replying to fitztrev:

Replying to mrmist:

jQuery('#pass1').val('');

This patch isn't working.

It worked for me but then I only did the briefest of tests. Ninja's suggestion is probably one way forward, because otherwise you are constantly attempting to out-code the browser agent.

It seems to me to be a bug in FF anyway to be filling in the password fields on an unknown form.

#19 @mrmist
11 years ago

  • Keywords has-patch removed

#20 @westi
11 years ago

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

(In [9347]) Set autocomplete off for password files on the profile pages. Fixes #5006.

#21 @westi
11 years ago

  • Milestone changed from 2.9 to 2.8

That works for me in FF3

#22 @jacobsantos
11 years ago

  • Milestone changed from 2.8 to 2.7
Note: See TracTickets for help on using tickets.