© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hmm, this isn't actually a dupe.
The problem here seems to actually be in autocomplete code. If you type "USERNAME" in a field and hit tab (without selecting "username" from the autocomplete dropdown), we still get a DOMAutoComplete event, and the value of the text field has already been changed to the lowercase value. So it's been changed before password manager even gets around to looking at it.
It's a little odd that DOMAutoComplete fires, since a value wasn't actually selected. That does allow eliminating a tedious manual selection step (typing "username<tab>" and having the login filled is nice), but maybe that should be implemented as a special case, dunno... We already have a blur listener. [When then fires after the autocomplete event, so we stupidly run the formFill code again.]
But fixing this while preserving bug 499649 could be kind of messy... We'd need to add code to do case-insensitive matching in fillForm(), and decide if onFormSubit() should be case-insensitive too [ie, if we should offer to save the "new" login, or recognize it as the old login / password change.]
Another possibility would be to just special case the autocomplete code to not change the field value after a tab/blur. That might actually be best...