Bug 1129619 (2015-login-capture-UX)

Login Capture Doorhanger

NEW
Unassigned

Status

()

Toolkit
Password Manager
--
enhancement
3 years ago
2 months ago

People

(Reporter: rfeeley, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [passwords:capture-UI], URL)

User Story

As a user I want FF to capture my logins and let me know in the UI.
(Reporter)

Description

3 years ago
When asking the user if they want to remember a login, allow them to review and edit the login.

* When user clicks username field, it becomes focused and editable
* When user clicks password field, it becomes revealed, focused and editable
* When user changes either field "Never remember" button changes to "Revert changes" which reverts to captured credentials

Details on Capture tab of Lucidchart doc
(Reporter)

Updated

3 years ago
Depends on: 1128683
Actions for Ryan:

1) Decide whether we need labels on the username and password inputs. The concern is if we didn't capture the username or captured the wrong data as the username (e.g., the user's zip code), it may not be obvious to the user what she's looking at.

2) Decide what messaging we do in the "missing username" case. It may be we didn't capture it (e.g., reset password flow) or the might actually not be a username (e.g., PIN, or mailman). The current design calls for a red outline and text in the username, which may be too strong.
Flags: needinfo?(rfeeley)
(Reporter)

Comment 2

3 years ago
Discussed with Stephen Horlander it was decided that:

1. We should not add field specific labels
2. We should not add validation (e.g. red) because no username may as desired.
2. Instead we add placeholder (field hints) for each field. If the username is empty, the user can edit it.

(already pdated in LucidChart)

HOWEVER, this brings up an issue I currently experience in my password manager. Typically when the user does a password reset or a "continue as user" login, no username will be captured, even though an existing username and password may be stored.

What we don't want is multiple logins for a site, some having a username, others not. Passwords the same or different, this is a terrible example.

How can we avoid this situation?
Flags: needinfo?(rfeeley)
(Reporter)

Comment 3

3 years ago
… because what will happen when you next log in is that Firefox will fill the entry with the username, and not just the one with the new password.
> HOWEVER, this brings up an issue I currently experience in my password manager. Typically when the user does a password reset or a "continue as user" login, no username will be captured, even though an existing username and password may be stored.

> What we don't want is multiple logins for a site, some having a username, others not. Passwords the same or different, this is a terrible example.

We have options, like letting the user select among previously saved usernames for the site when we fail to capture a username. There are some weird corner cases that need to be specified, like when some of the previously saved logins are missing usernames, too.

What do you think should happen? You should consider all the cases, e.g., including the situations where the user may already have one or more saved logins for the site, which may or may not be missing a username for each.
Priority: -- → P1
See Also: → bug 551948
Assignee: nobody → paolo.mozmail
Blocks: 1118955
See Also: → bug 1088220
(Reporter)

Updated

3 years ago
Summary: Allow the user to edit the captured username or password before saving → Ask the user if they would like to save and optionally edit a detected login
Hi Paolo, can you provide a point value.
Status: NEW → ASSIGNED
Iteration: --- → 39.1 - 9 Mar
Flags: qe-verify?
Flags: needinfo?(paolo.mozmail)
Flags: firefox-backlog+

Comment 6

3 years ago
(In reply to Marco Mucci [:MarcoM] from comment #5)
> Hi Paolo, can you provide a point value.

I'll probably break this down in smaller increments so let's go for 13 for now.
Points: --- → 13
Flags: qe-verify?
Flags: qe-verify+
Flags: needinfo?(paolo.mozmail)

Updated

3 years ago
Iteration: 39.1 - 9 Mar → 39.2 - 23 Mar

Updated

3 years ago
Blocks: 1141601

Comment 7

3 years ago
This isn't blocked by the anchor improvements.
No longer depends on: 1128683

Updated

2 years ago
Iteration: 39.2 - 23 Mar → 39.3 - 30 Mar

Updated

2 years ago
Iteration: 39.3 - 30 Mar → 40.1 - 13 Apr
Paolo: what's the deal with this bug? Is it tracking any actionable work or is it just a meta bug? Are you working on it currently or focusing on other things? It's assigned to 40.1 but has been carried over 3 times, so it seems like something needs to change about how we are tracking any work it represents.
Flags: needinfo?(paolo.mozmail)

Comment 9

2 years ago
Yeah, this is actually a meta-bug, although the work I already completed in Q1 is tracked in bug 1141601. I think the confusion initially derived from a different usage of the assigned state.
Status: ASSIGNED → NEW
Iteration: 40.1 - 13 Apr → ---
Points: 13 → ---
Flags: qe-verify+
Flags: needinfo?(paolo.mozmail)
Keywords: meta

Updated

2 years ago
Depends on: 1153217

Updated

2 years ago
Depends on: 1153218

Comment 10

2 years ago
I've filed bug 1153217 and bug 1153218 for the remaining work related to the capture doorhanger. I'm not working on these right now as I'm focusing on a prototype of the fill doorhanger. Since the capture interface may eventually become integrated with the fill interface, it's possible that these features will be placed in the fill doorhanger instead.

Updated

2 years ago
Flags: firefox-backlog+

Updated

2 years ago
Summary: Ask the user if they would like to save and optionally edit a detected login → Login Capture Doorhanger
Moving capture-related dependencies from bug 1141601.
Alias: 2015-login-capture-UX

Updated

2 years ago
User Story: (updated)

Updated

2 years ago
Whiteboard: UI-improvement
Depends on: 1187663
(Reporter)

Comment 12

2 years ago
To be subsumed by future Control Center bugs.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
Capture doesn't fall under Control Center AFAIK and this is a meta bug where we actually did implement all but 2 dependencies.
Assignee: paolo.mozmail → nobody
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Status: REOPENED → NEW
Whiteboard: UI-improvement → [passwords:capture-UI]
Removing priority from meta bug
Priority: P1 → --
You need to log in before you can comment on or make changes to this bug.