If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

autocomplete changes the input's value to the case of a matching entry (FOO --> foo).

RESOLVED DUPLICATE of bug 499649

Status

()

Toolkit
Password Manager
RESOLVED DUPLICATE of bug 499649
8 years ago
3 years ago

People

(Reporter: tutufan, Unassigned)

Tracking

1.9.1 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2

While trying to join IEEE at www.ieee.org, while creating an account, they require the desired username to be entered in all capital letters (stupid, yes, but not illegal).  If I try to enter an uppercase username that Firefox already has a lowercase cognate for, it will replace the uppercase username with lowercase.  There appears to be no way at all to enter the uppercase version.

Reproducible: Always



Expected Results:  
Firefox needs to fastidiously avoid case-smashing for completion boxes.  We live in a mixed-case world, and Firefox should support it.  In particular, if the user types in "ABCDE", Firefox should *never* correct this to 'abcde'.
Component: General → Password Manager
Product: Firefox → Toolkit
QA Contact: general → password.manager
Whiteboard: [DUPEME]
Version: unspecified → 1.9.1 Branch
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 499649
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...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Whiteboard: [DUPEME]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: username suggest/completion does not allow entry of UPPERCASE usernames → autocomplete changes the input's value to the case of a matching entry (FOO --> foo).

Updated

7 years ago

Updated

7 years ago
Duplicate of this bug: 583597

Updated

7 years ago
Duplicate of this bug: 587973
Duplicate of this bug: 667970
Duplicate of this bug: 732626
Status: NEW → RESOLVED
Last Resolved: 8 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 499649
You need to log in before you can comment on or make changes to this bug.