Closed Bug 1129619 (2015-login-capture-UX) Opened 9 years ago Closed 6 years ago

Login Capture Doorhanger

Categories

(Toolkit :: Password Manager, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: rfeeley, Unassigned)

References

()

Details

(Keywords: meta, Whiteboard: [passwords:capture-UI])

User Story

As a user I want FF to capture my logins and let me know in the UI.
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
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)
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)
… 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: → 551948
Assignee: nobody → paolo.mozmail
See Also: → 1088220
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+
(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)
Iteration: 39.1 - 9 Mar → 39.2 - 23 Mar
This isn't blocked by the anchor improvements.
No longer depends on: 1128683
Iteration: 39.2 - 23 Mar → 39.3 - 30 Mar
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)
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
Depends on: 1153217
Depends on: 1153218
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.
Flags: firefox-backlog+
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
User Story: (updated)
Whiteboard: UI-improvement
Depends on: 1187663
To be subsumed by future Control Center bugs.
Status: NEW → RESOLVED
Closed: 8 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 → --
Status: NEW → RESOLVED
Closed: 8 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.