Closed Bug 1558857 Opened 5 months ago Closed 29 days ago

Password autofill suggestions have become unusable on sites where the user has a lot of passwords saved on eTLD+N domains where N>1

Categories

(Toolkit :: Password Manager, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: ehsan, Assigned: sfoster)

References

(Regression)

Details

(Keywords: regression)

User Story

Visually distinguish same-domain logins with "From this website"

Attachments

(5 files)

I have many passwords saved for foo.mozilla.org where foo is a Mozilla subdomain. I just tried to log in to bugzilla.mozilla.org and Nightly offered me a long list of user name suggestions from every mozilla.org subdomain I have ever saved a password on. The list probably amounts to somewhere around 30 to 40 saved logins. The worst part about that was that the list was as wide as the Bugzilla user name text box, which meant I couldn't even read most of the suggestions, so I gave up trying to find the correct one from the list after a minute or two of scrolling around and typed it all out from memory.

To summarize, as a result of this change, the password manager autofill is essentially unusable for me on sites where I have saved a lot of logins for various eTLD+N's where N>1. It would be nice if Firefox would go back to the previous behaviour where it used to suggest and autofill the exact right login for the origin I am visiting not all of the possible related ones for the sibling eTLD+N's.

This is controlled by the signon.includeOtherSubdomainsInLookup pref, but before just toggling that off it would be good to try and figure out a better user experience for you. It sounds like increasing the minimum width of the autocomplete menu would help? Do you have any other suggestions for how to make this more usable in cases like this where there are a lot of matches?

Flags: needinfo?(ehsan)

Were you running a build with bug 1555210? If so, it should have sorted the BMO logins to the top. I personally think we should follow Safari and replace the origin line with "From this site" when a login origin matches the site you're on so that the user doesn't have to manually compare.

Note that we already try to dedupe passwords so you shouldn't see multiple rows for the same password unless we have a bug.

Regressed by: 589628
Attached image Screenshot

Thanks Sam and Matt for the comments. So I think there might be a few problems at play here, I'm gonna try my best to expand on this by separating out the issues.

  • First and foremost, I believe Matt may be right in that the first time I may have tried a build before bug 1555210... (I wish I had saved a screenshot.) I remember that I couldn't figure out what the results were sorted by.
  • Now the results are indeed sorted by placing passwords from this origin first, which makes things very slightly better. More on the very slightly part below.
  • I believe the width of the autocomplete box is part of the problem. Please see this screenshot and tell me what's the difference between the 3rd and fourth suggestions. ;-) (Note that the screenshot is clipped to protect the privacy of individuals who had logged into Bugzilla on my account.) While talking about that, I for one have no idea where the first result ever came from, and I do not remember having ever seen it before this UI changed visually recently. Now when logging in to Bugzilla I pick between the 1st, 3rd and 4th results randomly because I have no clue what login is actually saved behind them.
  • The signon.includeOtherSubdomainsInLookup pref makes me actually able to use the password manager to log in to Bugzilla again. I tried to figure out why that is, because now that the results from bugzilla.mozilla.org are at the top, this difference shouldn't exist. I think this may go back to the sheer number of entries in the suggestion autocomplete box without this pref. I counted them and I get 20 results in that configuration. That is a bewildering number of choices to me at least, and in all honesty I think if I hadn't filed this bug I wasn't too sure if I would have gotten over the choice paralysis that this new UI induces in me to even get to the point of figuring out the results are sorted. The list of origins right now all look to me like "blah.mozilla.org" in light gray, not all too helpful in telling me which is the one I need to look at. I really want to iterate on this point that the number of choices in the current UI completely overwhelmed me and detracted me from using it (and in all honesty this kind of UI in other application would make me not use it ever again...)
  • Not having used Safari it's hard for me to say whether their UI would be much better in this regard but "From this site" sounds like something I would understand a lot easier than running string comparisons on 20 strings in parallel in my brain... :-)
Flags: needinfo?(ehsan)

Giving this a priority to take it out of the triage list. Thanks for the details :ehsan, lets continue to figure out the best fix for this, as attachment #9071959 [details] is clearly not a great user experience.

Priority: -- → P3
See Also: → 1561673

This should be a priority after Skyline work.

Priority: P3 → P2
Assignee: nobody → sfoster
Status: NEW → ASSIGNED
  • I believe the width of the autocomplete box is part of the problem.

Bug 1554458 increased the minimum width of the autocomplete popup, which should have a helped a little with this part of the issue.

.... I counted them and I get 20 results in that configuration. That is a bewildering number of choices to me at least, and in all honesty I think if I hadn't filed this bug I wasn't too sure if I would have gotten over the choice paralysis that this new UI induces in me ..

The experience offered by the autocomplete UI does get worse when the number of matches grows. If you have 20 different accounts on some site, you'll get a popup with 20 choices. And this could be compounded when we include subdomain matches. It may be that the flat list of options the autocomplete UI provides just isn't a good fit for these cases, but for this bug I'll see if we can improve it incrementally.

For reference, this is Safari's autocomplete UI when there are login matches from different subdomains

Attached file anonLogins.js

This defines a anonymizeLogins(logins) function which can be used to output all your saved logins in a useful-yet-anonymized way.

Usage: In the browser console / browser toolbox, paste the contents of this script into the console, or use the scratchpad to load it, and then call:

anonymizeLogins( Services.logins.getAllLogins() );

The return value will be an array of vanilla javascript objects. If you copy that whole array (right-click, copy object) you can drop that into a file. It preserves the various timestamps but substitutes all the other usernames/passwords/origins etc. E.g. bugzilla.mozilla.org might become "xxxxxx26.xxxxxx8.org". The numbers increment for each new unique word in the logins provided, so the result is different with each profile. But internally consistent so if you have 20 b.m.o logins, that output will have 20 xxxxxx26.xxxxxx8.org logins.

Ehsan, can you run attachment 9097806 [details] code in the Browser Console and then run the following afterwards and attach the output string:

anonymizeLogins(LoginManagerParent._searchAndDedupeLogins("https://bugzilla.mozilla.org", {
        formActionOrigin: "",
        ignoreActionAndRealm: true,
        acceptDifferentSubdomains: true,
      }).filter(function(fullMatch) {
      let match = fullMatch.username;
      return match;
    })).map(login => [login.origin, login.formActionOrigin, login.httpRealm, login.username, login.password].join(", ")).join("\n");

That will let us confirm that the deduping is working correctly.

Flags: needinfo?(ehsan)

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #10)

Ehsan, can you run attachment 9097806 [details] code in the Browser Console and then run the following afterwards and attach the output string:

anonymizeLogins(LoginManagerParent._searchAndDedupeLogins("https://bugzilla.mozilla.org", {
        formActionOrigin: "",
        ignoreActionAndRealm: true,
        acceptDifferentSubdomains: true,
      }).filter(function(fullMatch) {
      let match = fullMatch.username;
      return match;
    })).map(login => [login.origin, login.formActionOrigin, login.httpRealm, login.username, login.password].join(", ")).join("\n");

That will let us confirm that the deduping is working correctly.

"https://xxxx2.xxxxxx3.org, https://xxxx2.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxx0, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1
https://xxxx7.xxxxxx3.org, https://xxxx7.xxxxxx3.org, , xxxxxxxxxxxxxxxx6, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1
https://xxxxxx11.xxxxxx3.org, https://xxxxxx11.xxxxxx3.org, , xxxxxx10, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1
https://xxxxxx15.xxxxxx3.org, https://xxxxxx15.xxxxxx3.org, , xxxxxxxxxxxxxxxx6, xxxxxxxxxx14
https://xxxxxxx20.xxxxxx3.org, https://xxxxxxx20.xxxxxx3.org, , xxx18, xxxxx19
https://xxxxx24.xxxxxx3.org, https://xxxxx24.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxx23, xxxxx19
https://xxx28.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx29, xxxxxxxxxxxxxxxxxxxxx23, xxxxxxxxxxxxxxxxxxxxxxxx27
https://xxxxxx15.xxxxxx3.org, , xxxxxxxxxxx30, xxxxxxxxxxxxxxxx6, xxxxx19
https://xxxxxx15.xxxxxx3.org, https://xxxxxx15.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxxx31, xxxxx32
https://xxxx34.xxxxxx3.org, https://xxxx34.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxx23, xxxxxxxxxxxx33
https://xx38.xxxxxx3.org, https://xx38.xxxxxx3.org, , xxx37, xxxxx19
https://xxxxxxxxxxx41.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx42, xxxxx39, xxx40
https://xx44.xxxxxx3.org, https://xx44.xxxxxx3.org, , xxxxxxxxxxx43, xxxxx19
https://xx48.xxxxxx3.org, https://xx48.xxxxxx3.org, , xxx18, xxxxxxxxxx47
https://xxxxxx15.xxxxxx3.org, https://xxxxxx15.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxx23, xxxxxxxxxxxx49
http://xxxx52.xxxxxx3.org, , xxxxxxxxxxxxxxxx53, xx50, xxxx51
https://xx44.xxxxxx3.org, https://xx44.xxxxxx3.org, , xxxxxxxxxxxxxxxx6, xxxxxx54
https://xxxx2.xxxxxx3.org, https://xxxx2.xxxxxx3.org, , xxxxxxxxxx56, xxxxxxxxxxxx49
https://xxxxxxxxx57.xxxxxx3.org, https://xxxxxxxxx57.xxxxxx3.org, , xxxxxxxxxxxxxxxx6, xxxxxxxxxxxx49
https://xxxxxx15.xxxxxx3.org, https://xxxxxx15.xxxxxx3.org, , xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx58, xxxxxxxxxx14"
Flags: needinfo?(ehsan)

That looks correct to me ( you can sub xxxx2. -> bugzilla. and xxxxxx3.org -> mozilla.org to unobfuscate it a bit.) LoginAutoCompleteResult will sort the results so the bugzilla.mozilla.org records should be grouped at the top of the menu. And while 20 results is not in the middle of the bell curve, its not an unreasonable number to be able to navigate in the autocomplete UI.

I think a fix for this bug will need some UX input. Ryan, you mentioned you had some thoughts about this, and specifically Safari's "from this site" treatment. Can you summarize or link what the ideal output would be for this scenario and I'll see what steps we can take to get us there?

Flags: needinfo?(rgaddis)

Thank Ehsan,

I put your results into a spreadsheet to make it easier to analyze. I agree with Sam that I think the de-duping is working properly, it's simply that you have too many stale passwords saved for these subdomains… partly because we didn't have subdomain suggestions already in the browser… i.e. we're in a chicken-and-egg scenario where the subdomain suggestion feature would have prevented your list from being so long but enabling the feature will expose users to their existing messes caused by not having the feature. I think will have to rely somewhat on users cleaning up their old logins but also explore UX improvements like the ones I put in the User Story:

  • Visually distinguish same-domain logins such as saying "from this site" instead of the domain and/or showing a separator line between the same-site and other eTLD+1 matches.
Flags: needinfo?(rgaddis)

Katie we'll need to address this issue first in our priority list, pending the completion of the Vulnerable Passwords work. Can you flag this to Markus for appropriate tagging association for work being tracked?

Flags: needinfo?(kcaldwell)
Flags: needinfo?(rgaddis)

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #13)

Thank Ehsan,

I put your results into a spreadsheet to make it easier to analyze. I agree with Sam that I think the de-duping is working properly, it's simply that you have too many stale passwords saved for these subdomains… partly because we didn't have subdomain suggestions already in the browser… i.e. we're in a chicken-and-egg scenario where the subdomain suggestion feature would have prevented your list from being so long but enabling the feature will expose users to their existing messes caused by not having the feature.

That makes perfect sense.

I think will have to rely somewhat on users cleaning up their old logins but also explore UX improvements like the ones I put in the User Story:

  • Visually distinguish same-domain logins such as saying "from this site" instead of the domain and/or showing a separator line between the same-site and other eTLD+1 matches.

Do we think users are actually able to do that? I'm personally at a loss as to how I would go about doing that, and I'd like to think of myself as a fairly advanced browser user... (Part of it is connecting the problem of "I can't fill in passwords to the site I used to be able to log in to" to the solution of "I need to clean up my passwords database" and the other part of it is the how to of "I need to clean up my passwords database", both of which are non-obvious to me.)

Also, do we have any other bits of data saved in the password manager that could help us suggest something useful? For example, do we persist the last used timestamp on passwords, so that we can avoid suggesting passwords that I've not used in the last year if one is available that I've used in the last week/month, etc.?

(In reply to rgaddis from comment #14)

Katie we'll need to address this issue first in our priority list, pending the completion of the Vulnerable Passwords work. Can you flag this to Markus for appropriate tagging association for work being tracked?

Yes, noted.

Flags: needinfo?(kcaldwell)

I'm not working on this currently while it is waiting for UX

Status: ASSIGNED → NEW

Katie, would you be fine with an incremental, parity-Safari approach for Fx71 (deadline of this week) and then we can figure out a better solution later? This just means changing the exact domain matches to say "From this website" instead of showing the domain and requiring the user to compare it to the address bar to ensure they're not getting phished on a subdomain (which seems tedious and error-prone), see attachment 9097792 [details]. I think Safari's approach is much more clear anyways, even for users with only a few subdomain logins.

Flags: needinfo?(kcaldwell)

Please see attachment / screenshot
When the origin has 1 or more exact matches, update the meta data string from web address to “From this website”. This will make it easier to differentiate from other subdomains.

Subsequent subdomain matching logins listed below. No changes to sort order

Flags: needinfo?(kcaldwell)

It may also be worth calling out/discussing whether or not we need to implement a longer, min-width for this field, to ensure that usernames are easily read on sites with small login forms.

Flags: needinfo?(rgaddis)

I think Sam mention there is a min width for the drawer... Sam do you know what it is currently set to?

Flags: needinfo?(sfoster)

(In reply to katieC from comment #21)

I think Sam mention there is a min width for the drawer... Sam do you know what it is currently set to?

We last touched this in bug 1554458, where we set it to min-width: 17em, and 21em when the generated password menu item is present.

Flags: needinfo?(sfoster)
Attachment #9102039 - Attachment description: Bug 1558857 - Display 'From this site' matched-origin logins in the autocomplete menu. r?MattN → Bug 1558857 - Display 'From this website' for matched-origin logins in the autocomplete menu. r?MattN
Status: NEW → ASSIGNED
User Story: (updated)
Pushed by sfoster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/275878558e61
Display 'From this website' for matched-origin logins in the autocomplete menu. r=MattN
Status: ASSIGNED → RESOLVED
Closed: 29 days ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Depends on: 1590362
Depends on: 1590622
Regressions: 1590622
No longer regressions: 1590622
You need to log in before you can comment on or make changes to this bug.