I came across this before, and I do not mind (because I clear the field)
But my users complain that they can not understand "my account" behavior, going to my account automatically fills the first field
and they think they are "committed" to change your password, they receive an error message that the passwords do not match

I researched the subject and the phenomenon (it's not a bug that feature...) happens when the user allow the browser to remember his password, this happens to me when i used FireFox and chrome (did not checked in IE, but I expect it to happen there too)

Drupal relevant links
http://drupal.org/node/751198 http://drupal.org/node/751198
http://drupal.org/node/280535 http://drupal.org/node/280535

possible solution
http://www.verysimple.com/blog/2007/03/07/forcing-firefox-to-obey-autoco... http://www.verysimple.com/blog/2007/03/07/forcing-firefox-to-obey-autoco ...

and here is a drupal solution,
http://www.metaltoad.com/blog/autocomplete-clearing-form-values-and-drup... http://www.metaltoad.com/blog/autocomplete-clearing-form-values-and-drup ...

i did not check it but i guess this solves the problem

The Funny / Sad thing is that there is no way to get over it but by changing the core code

Did you encountered this phenomenon?
How do you think this problem can be solved ?

Thanx
Avior

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

avior’s picture

a non code possible solution might be moving the change password fields to another form (will not be included in the my account form),
so the problem still exist but it would be less critical, because only users that want to change passwords will use this form

this is relevant to drupal >= 7.x too

avior’s picture

Version: 6.x-dev » 7.x-dev

this is 7.x issue too
someone ?

rafamd’s picture

Category: feature » bug

Correct link for the "drupal solution" mentioned in the original post:
http://www.metaltoad.com/blog/autocomplete-clearing-form-values-and-drup...

I think this is more of a bug than a feature request.

zero2one’s picture

Status: Active » Needs review
FileSize
493 bytes

This is an usability issue :-)

Patch attached.

Please review!

it_mohit’s picture

Instead of patching its better to use form_alter here. Alter the password field in your custom module

Thanks
Mohit Sharma

http://www.mohitsharma.net

Shyamala’s picture

Status: Needs review » Reviewed & tested by the community

#4 Works fine.

webchick’s picture

Version: 7.x-dev » 8.x-dev
Status: Reviewed & tested by the community » Fixed
Issue tags: +Needs backport to D7

Ick, that's a nasty little bug. I can totally see how that would be confusing for people.

Tested the patch and it works great. I did make one minor adjustment, which is to add an extra space before 'off'; please see the coding standards page for more info.

Committed and pushed to 8.x and 7.x. Thanks!

David_Rothstein’s picture

Status: Fixed » Needs work

The 'autocomplete' attribute is invalid XHTML, so I think we should only use it if there's a really good reason.

I'm not sure what the reason is here. The original post above reported two issues:

  1. ...going to my account automatically fills the first field and they think they are "committed" to change your password...

    If there's confusion around this point, then we should fix it by changing the help text (since the wording of the current help text is the only thing that could be giving them the impression that they are required to change the password). This same confusion could certainly arise for users without password autocomplete too, so I don't think the autocomplete change really fixed it either (even ignoring the invalid XHTML issue).

  2. ...they receive an error message that the passwords do not match...

    I can't reproduce any problem here currently. Can anyone else? I think whatever this was may have gotten fixed elsewhere in the interim?

David_Rothstein’s picture

Status: Needs work » Needs review
FileSize
1.39 KB

Here's a patch that tries to improve the help text on the current password field so that users do not feel like they are "committed" to changing their email/password when it's filled in (regardless of whether it was their browser autocomplete that filled it in or something else).

This changes strings, so it may only be appropriate for D8. However, for D7 I think we should still roll back the 'autocomplete' part unless there's more info on why we need it...

David_Rothstein’s picture

The word "only" might not be adding much there - removed in the attached version.

rafamd’s picture

Hi David, besides having the password autocompleted isn't the expected behavior, it breaks the whole purpose of requesting the password in that form (which is making sure the actual user is changing the e-mail or password and not anyone else that found the logged in account).

It's a pity the autocomplete isn't valid xhtml, maybe we could consider another fix ?

cheers

webchick’s picture

Dang. The XHTML compliance break really sucks. :( But introducing more text to explain a stupid interface problem doesn't make me very excited, either. There was a JS solution in one of the blog posts referenced in the OP, though that means adding even more code...

David_Rothstein’s picture

Hi David, besides having the password autocompleted isn't the expected behavior, it breaks the whole purpose of requesting the password in that form (which is making sure the actual user is changing the e-mail or password and not anyone else that found the logged in account).

This is a good point (though in general with a Drupal site if you let the browser password manager run on a public computer you are in big trouble anyway, this may be the one place that deserves extra protection).

But introducing more text to explain a stupid interface problem doesn't make me very excited, either.

The above patch does not really change the amount of text (if anything, it makes it shorter!).

In general, though, the whole experience of having the "current password" field appear no matter what on this form (as opposed to e.g. in a confirmation form afterwards) is probably what's really broken here. I think there may be an issue to fix that somewhere, but I don't know offhand where it is.

rafamd’s picture

David, I've been through the user.module issues and didn't find one explicitly proposing current password confirmation only when e-mail or pass want to be changed (there are others that propose related changes though).

I think we should stay on focus and have this little fix (prevent the current password field to be automatically filled), because, wouldn't we have the same problem this issue describes if we ask for the current password confirmation in a separate form afterwards ?? (or anywhere else ?)

swentel’s picture

Marked #380250: password field in user prfile edit autocompletes in browsers as a duplicate as there are patches here already. To me, this is a really big wtf which valids the use of the autocomplete attribute.
http://drupal.org/project/clear_password_field uses jQuery as a solution - and it also has a good screenshot explaining the root of the problem.

coltrane’s picture

Marked #1094402: Disable autocomplete on user_edit form as a duplicate, a patch for this issue in Drupal 7

coltrane’s picture

Would we consider including autocomplete disable of the password field on login forms with this issue, or should it be separate?

A third-party vendors stance on this issue:

Autocomplete is a feature offered by many web browsers to store previously entered values for fields on web pages. While this feature is helpful in many cases, it should not be enabled for fields that contain sensitive values (like password or social security number (SSN)), as an attacker can retrieve the previously entered values if the attacker has local access to the machine.

Everett Zufelt’s picture

FYI:

autocomplete="off" is completely valid html5.

http://www.w3.org/TR/html5/common-input-element-attributes.html#the-auto...

Everett Zufelt’s picture

RKS’s picture

The release notes for 7.9 lists this as fixed. It also lists zero2one so was his patch used or David's? Also, should we mark this issue fixed now?

danillonunes’s picture

I agree with #9 about rollback the autocomplete patch. For D7, this issue was unintentionally fixed with #86299: Add "current password" field to "change password form". So it's unnecessary to break the XHTML markup.

For D8, the autocomplete="off" should remain since HTML5 will be adopted.

webchick’s picture

No, this wasn't unintentionally fixed as a result of #86299: Add "current password" field to "change password form". That patch in fact caused this usability bug, which the patch committed to 7.9 fixes.

This is a very direct, user-facing bug, so I'm not into reverting autocomplete="off" in D7 without a suitable non-XHTML-breaking JS equivalent. And that sounds like it'll be a lot of extra code. :\

danillonunes’s picture

I don't think so. The error message (The specified passwords do not match.) of the original report and their related bugs happens when the first "Password" field of the pair of fields for change password is auto filled (and the other "Confirm password" field is left in blank).

With the introducion of the "Current password" field (from #86299), it is that is auto filled by the browsers instead of the other two new password fields, which now statys in blank. Submitting the form in this way don't causes any errors.

Also, I think the users feels "committed" to change their passwords just because of the thrown error message, not because the password field is auto filled by their browsers.

rafamd’s picture

@danillonunes, what you say in #23 is understandable and correct, but still, that field isn't meant to be filled (even for the mentioned security reasons).

Now, this should be a matter of evaluating the trade-off, I think.

David_Rothstein’s picture

Ah! Thanks for that explanation, @danillonunes. That entirely explains my confusion in #8 (where I said I couldn't reproduce the original problem).

So to clarify:

  1. The original bug report here was against Drupal 6, not 7.
  2. There is indeed a serious usability problem with this form in Drupal 6, exactly as the original reporter described.
  3. In Drupal 7 and above, #86299: Add "current password" field to "change password form" inadvertently fixed the usability problem (and fixed it before this issue was ever filed, actually).
  4. There may be leftover usability issues also, but they're definitely not as serious.

So, it's not clear if adding the 'autocomplete' in Drupal 7 helped here or not. That said, the security argument (in #11) may be a good reason for leaving it anyway. That's more important than XHTML compliance, and is a valid point entirely separate from the usability question.

Therefore, attached is a patch which simply adds a code comment explaining the security rationale for having autocomplete turned off. Aftewards, we should consider backporting the autocomplete fix to Drupal 6 (or fixing it via a different method), because the usability problem there is pretty ugly.

I'll move the text change part of my patch from #9 to a different issue, because it turns out that isn't really related to the confusion that was originally reported here.

David_Rothstein’s picture

I moved the text changes from #9/#10 here: #1326172: Improve wording of the "Current password" field description on the user edit form

Also, in #13 I mentioned that for Drupal 8 we should consider changing this whole workflow anyway (to solve the remaining usability problem in a better way) and that there may be an existing issue for that. I eventually found the issue I was thinking of: #588550: Allow the user edit form to only ask for the current password when necessary (in a followup confirmation step). I'm going to go there and change the title of that, since "Drupal paranoia" (the current title) is not a very descriptive one :)

valthebald’s picture

Status: Needs review » Closed (duplicate)
David_Rothstein’s picture

Status: Closed (duplicate) » Needs review

I don't think so - that looks like it's dealing with different fields than this one. But I'll leave a comment there pointing to this issue too.

David_Rothstein’s picture

Issue tags: -Needs backport to D7

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, password-autocomplete-787876-25.patch, failed testing.

valthebald’s picture

Status: Needs work » Active

#29: it's easy to check that the problem is solved in D8. I have enabled autocomplete behavior (in FF and Chrome), and in user edit form original password field is empty. However, in D7 it is prepopulated.

David_Rothstein’s picture

The fix in this issue (autocomplete=off for the first password field) was committed to both D7 and D8. In my testing with Firefox, it works correctly for both; if there's a discrepancy, though, I think that's a topic for #1525640: Disable autocompletion for email/password field when editing user profile which only has a Drupal 8 commit so far.

I think here, we should just get that code comment in and then (possibly) backport to Drupal 6, where the usability problem was more serious?

Here is a reroll.

David_Rothstein’s picture

Status: Active » Needs review
valthebald’s picture

Status: Needs review » Reviewed & tested by the community

I think that comment from #32 is sufficient to close this issue, and focus on #1525640: Disable autocompletion for email/password field when editing user profile

catch’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Thanks. Committed/pushed. Assuming the comment should be backported to 7.x as well.

dcam’s picture

Status: Patch (to be ported) » Needs review
FileSize
670 bytes

Backported #32 to D7.

valthebald’s picture

Status: Needs review » Reviewed & tested by the community

No code change, comment matches #32

valthebald’s picture

No code change, comment matches #32. Marking RTBC

David_Rothstein’s picture

Version: 7.x-dev » 6.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)
Issue tags: +Needs backport to D6

Committed to 7.x - thanks! http://drupalcode.org/project/drupal.git/commit/ad00b25

(And fixed the line breaks so it wraps at 80 characters on 7.x.)

Tentatively moving back to Drupal 6 since the usability issue there was pretty serious, but I'm not sure what chance there is of actually fixing it in Drupal 6 at this point.

Status: Patch (to be ported) » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.