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
Comment | File | Size | Author |
---|---|---|---|
#36 | 787876-36-password-autocomplete.patch | 670 bytes | dcam |
#32 | password-autocomplete-787876-32.patch | 793 bytes | David_Rothstein |
#25 | password-autocomplete-787876-25.patch | 670 bytes | David_Rothstein |
#10 | password-autocomplete-787876-10.patch | 1.38 KB | David_Rothstein |
#9 | password-autocomplete-787876-9.patch | 1.39 KB | David_Rothstein |
Comments
Comment #1
avior CreditAttribution: avior commenteda 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
Comment #2
avior CreditAttribution: avior commentedthis is 7.x issue too
someone ?
Comment #3
rafamd CreditAttribution: rafamd commentedCorrect 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.
Comment #4
zero2one CreditAttribution: zero2one commentedThis is an usability issue :-)
Patch attached.
Please review!
Comment #5
it_mohit CreditAttribution: it_mohit commentedInstead of patching its better to use form_alter here. Alter the password field in your custom module
Thanks
Mohit Sharma
http://www.mohitsharma.net
Comment #6
Shyamala CreditAttribution: Shyamala commented#4 Works fine.
Comment #7
webchickIck, 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!
Comment #8
David_Rothstein CreditAttribution: David_Rothstein commentedThe '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:
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).
I can't reproduce any problem here currently. Can anyone else? I think whatever this was may have gotten fixed elsewhere in the interim?
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedHere'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...
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedThe word "only" might not be adding much there - removed in the attached version.
Comment #11
rafamd CreditAttribution: rafamd commentedHi 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
Comment #12
webchickDang. 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...
Comment #13
David_Rothstein CreditAttribution: David_Rothstein commentedThis 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).
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.
Comment #14
rafamd CreditAttribution: rafamd commentedDavid, 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 ?)
Comment #15
swentel CreditAttribution: swentel commentedMarked #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.
Comment #16
coltraneMarked #1094402: Disable autocomplete on user_edit form as a duplicate, a patch for this issue in Drupal 7
Comment #17
coltraneWould 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:
Comment #18
Everett Zufelt CreditAttribution: Everett Zufelt commentedFYI:
autocomplete="off" is completely valid html5.
http://www.w3.org/TR/html5/common-input-element-attributes.html#the-auto...
Comment #19
Everett Zufelt CreditAttribution: Everett Zufelt commentedSee #1275764: Add a dedicated #autocomplete property to Form API form elements
Comment #20
RKS CreditAttribution: RKS commentedThe 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?
Comment #21
danillonunes CreditAttribution: danillonunes commentedI 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.
Comment #22
webchickNo, 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. :\
Comment #23
danillonunes CreditAttribution: danillonunes commentedI 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.
Comment #24
rafamd CreditAttribution: rafamd commented@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.
Comment #25
David_Rothstein CreditAttribution: David_Rothstein commentedAh! 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:
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.
Comment #26
David_Rothstein CreditAttribution: David_Rothstein commentedI 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 :)
Comment #27
valthebaldDuplicates (fixed) #1525640: Disable autocompletion for email/password field when editing user profile
Comment #28
David_Rothstein CreditAttribution: David_Rothstein commentedI 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.
Comment #29
David_Rothstein CreditAttribution: David_Rothstein commented#25: password-autocomplete-787876-25.patch queued for re-testing.
Comment #31
valthebald#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.
Comment #32
David_Rothstein CreditAttribution: David_Rothstein commentedThe 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.
Comment #33
David_Rothstein CreditAttribution: David_Rothstein commentedComment #34
valthebaldI 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
Comment #35
catchThanks. Committed/pushed. Assuming the comment should be backported to 7.x as well.
Comment #36
dcam CreditAttribution: dcam commentedBackported #32 to D7.
Comment #37
valthebaldNo code change, comment matches #32
Comment #38
valthebaldNo code change, comment matches #32. Marking RTBC
Comment #39
David_Rothstein CreditAttribution: David_Rothstein commentedCommitted 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.