This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25236 - autocomplete fields: password types
Summary: autocomplete fields: password types
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P1 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-02 19:50 UTC by Ian 'Hixie' Hickson
Modified: 2014-04-14 18:03 UTC (History)
6 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2014-04-02 19:50:36 UTC
It would be useful for change-of-password fields for there to be a new autofill field that indicates that the password is a new one, as in:

   <input type=password name=newpassword autocomplete="new-password">
   <input type=password name=confpassword autocomplete="new-password">
Comment 1 Mike West 2014-04-03 09:01:34 UTC
Chrome will implement whatever syntax we agree upon here. The lack of a standard mechanism for signifying password/confirmation fields (as opposed to other fields of type 'password') is a pain point for our password autofill system.

I do believe there's value in distinguishing between new and confirmation password fields, if only because it allows us another heuristic with which to distinguish between "Sign _up_" and "Sign _in_" forms. If we wanted to be super clear, of course, we could add some metadata to the form itself.
Comment 2 Mike West 2014-04-03 09:31:37 UTC
Also: as you mentioned on the list, UA's handling of "Change password" forms would benefit from being able to explicitly specify that a particular field of type 'password' is your old password. 'old-password' sounds like a reasonable value.
Comment 3 Ian 'Hixie' Hickson 2014-04-09 21:59:44 UTC
Can you elaborate on the new vs confirmation case?
Comment 4 Mike West 2014-04-10 07:25:55 UTC
I'm not sure what I was thinking when I typed that. Both the "new password" and "confirm new password" fields could be designated via the same autocomplete value. That shouldn't create any problems.
Comment 5 Edward O'Connor 2014-04-11 22:41:59 UTC
Safari would like to have old-/current- (unsure on naming) and new-password autocomplete tokens.
Comment 6 Ian 'Hixie' Hickson 2014-04-11 22:42:56 UTC
Should we not just assume that any field that is type=password and doesn't have an explicit autocomplete="" value is the current (aka old) password?
Comment 7 Ian 'Hixie' Hickson 2014-04-14 17:55:51 UTC
Evan pointed out to me privately that the problem with assuming that missing fields mean "current password" is that today there's lots of pages where it doesn't mean that.

But I really want to avoid having people write:

   <input type=password name=password autocomplete=current-password>

But maybe "current-password" is not so bad...
Comment 8 Ian 'Hixie' Hickson 2014-04-14 18:03:10 UTC
Ok, done.
Comment 9 contributor 2014-04-14 18:03:32 UTC
Checked in as WHATWG revision r8573.
Check-in comment: Add some autofill keywords for usernames and passwords.
http://html5.org/tools/web-apps-tracker?from=8572&to=8573