1129619 - (2015-login-capture-UX) Login Capture Doorhanger

Status: RESOLVED FIXED

(Toolkit :: Password Manager, enhancement)

Description

[Ryan Feeley [:rfeeley]]

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

Comment 1

[Chris Karlof [:ckarlof]]

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.

Comment 2

[Ryan Feeley [: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?

Comment 3

[Ryan Feeley [: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.

Comment 4

[Chris Karlof [:ckarlof]]

> 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.

Comment 5

[Marco Mucci [:MarcoM]]

Hi Paolo, can you provide a point value.

Comment 6

[:Paolo Amadini]

(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.

Comment 7

[:Paolo Amadini]

This isn't blocked by the anchor improvements.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 9

[:Paolo Amadini]

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.

Comment 10

[:Paolo Amadini]

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.

Comment 11

[Matthew N. [:MattN]]

Moving capture-related dependencies from bug 1141601.

Comment 12

[Ryan Feeley [:rfeeley]]

To be subsumed by future Control Center bugs.

Comment 13

[Matthew N. [:MattN]]

Capture doesn't fall under Control Center AFAIK and this is a meta bug where we actually did implement all but 2 dependencies.

Comment 14

[Matthew N. [:MattN]]

Removing priority from meta bug