github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-12 05:04:17 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

Android - Password being inserted in username field #1255

New Issue
Closed
opened 2025-11-26 22:43:00 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-26 22:43:00 -06:00
Owner
Copy Link

Originally created by @ehaynes99 on GitHub (Mar 26, 2021).

Describe the Bug

On sites with independent pages for username, password is filled for username.

Steps To Reproduce

  1. Store an amazon.com password
  2. Go to amazon.com
  3. Use "Auto-fill with Bitwarden"

Expected Result

The username is populated.

Actual Result

The password is populated.

Additional Context

While this is technically a dup of #1173, it was closed without resolution, and I would like to suggest at least removing the default behavior of inserting the password unless the field can be identified as a password field. Even if you can't detect/autofill a username field, it shouldn't just blindly insert the password in an <input type="email" field. These fields in particular tend to be leaky. E.g. they get stored in the browser's autofill, are frequently wired to JS validation (including third-party ones), and often have event handlers that fire requests to e.g. check for an SSO integration on focus lost.

However, other password managers handle this by just assuming username when it can't be determined to be a password field. While this isn't bulletproof, it generally has the desired behavior. In the event that it's wrong, I think it's still more in keeping with the principle of least surprise. E.g. Keepass has this fallback when no associated password field is present:
fcd3cddbc7/src/keepass2android/services/AutofillBase/StructureParser.cs (L130)

if (usernameFields.Any() == false)
{
    //for some pages with two-step login, we don't see a password field and don't display the autofill for non-manual requests. But if the user forces autofill, 
    //let's assume it is a username field:
    if (isManualRequest && !passwordFields.Any() && _editTextsWithoutHint.Count == 1)
    {
        usernameFields.Add(_editTextsWithoutHint.First());
    }
}
Originally created by @ehaynes99 on GitHub (Mar 26, 2021). ## Describe the Bug On sites with independent pages for username, password is filled for username. ## Steps To Reproduce 1. Store an amazon.com password 2. Go to amazon.com 3. Use "Auto-fill with Bitwarden" ## Expected Result The username is populated. ## Actual Result The password is populated. ## Additional Context While this is technically a dup of #1173, it was closed without resolution, and I would like to suggest at least removing the default behavior of inserting the password unless the field can be identified as a password field. Even if you can't detect/autofill a username field, it shouldn't just blindly insert the password in an `<input type="email"` field. These fields in particular tend to be leaky. E.g. they get stored in the browser's autofill, are frequently wired to JS validation (including third-party ones), and often have event handlers that fire requests to e.g. check for an SSO integration on focus lost. However, other password managers handle this by just assuming username when it can't be determined to be a password field. While this isn't bulletproof, it generally has the desired behavior. In the event that it's wrong, I think it's still more in keeping with the principle of least surprise. E.g. Keepass has this fallback when no associated password field is present: https://github.com/PhilippC/keepass2android/blob/fcd3cddbc7c7b9d5ea2ca34940d051e3262b6c90/src/keepass2android/services/AutofillBase/StructureParser.cs#L130 ```c# if (usernameFields.Any() == false) { //for some pages with two-step login, we don't see a password field and don't display the autofill for non-manual requests. But if the user forces autofill, //let's assume it is a username field: if (isManualRequest && !passwordFields.Any() && _editTextsWithoutHint.Count == 1) { usernameFields.Add(_editTextsWithoutHint.First()); } } ```
GiteaMirror commented 2025-11-26 22:43:01 -06:00
Author
Owner
Copy Link

@eliykat commented on GitHub (Apr 29, 2021):

Thanks for reporting this issue. Autofill problems can affect different sites, apps, or devices, and we’re working on improving this feature. To help us track and analyze affected sites, please lodge a report using the Google Form mentioned in this issue: #1389. Please also direct any discussion or questions to that issue. This issue will now be closed.

@eliykat commented on GitHub (Apr 29, 2021): Thanks for reporting this issue. Autofill problems can affect different sites, apps, or devices, and we’re working on improving this feature. To help us track and analyze affected sites, please lodge a report using the Google Form mentioned in this issue: #1389. Please also direct any discussion or questions to that issue. This issue will now be closed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#1255
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?