User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

The new 71.0 featue "Firefox now suggests saved logins from other subdomains of a site" is anoying in a corporate environment, since MOST of my logins are from our internal corporate domain.

So please, add a switch to return to the old modus operandi.

if you want to go back to the old behaviour, you can you can change the signon.includeOtherSubdomainsInLookup preference in about:config to false.

(In reply to stefan@fasieb.de from comment #0)

The new 71.0 featue "Firefox now suggests saved logins from other subdomains of a site" is anoying in a corporate environment, since MOST of my logins are from our internal corporate domain.

Could you provide more details about the problem? We de-duplicate the list of logins so if you are using the same username and password combinations on multiple subdomains of your company you would still only see one row in autocomplete. Do you intentionally have many different usernames and passwords combinations or should some be updated/deleted instead?

(In reply to [:philipp] from comment #1)

if you want to go back to the old behaviour, you can you can change the signon.includeOtherSubdomainsInLookup preference in about:config to false.

That won't be supported forever though it's okay in the short term.

Just for the off-topic: Why the hell this feature exists? What is purposed for???

(In reply to Alexander Balagurov from comment #3)

Just for the off-topic: Why the hell this feature exists? What is purposed for???

See the User Story field of bug 589628. It's something that Chrome and Safari also do since it really helps for those two use cases.

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

See the User Story field of bug 589628. It's something that Chrome and Safari also do since it really helps for those two use cases.

It's really frustruating when you use ~200 dev instances on subdomains. It has to be switcheable

(In reply to Alexander Balagurov from comment #5)

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

See the User Story field of bug 589628. It's something that Chrome and Safari also do since it really helps for those two use cases.

It's really frustruating when you use ~200 dev instances on subdomains. It has to be switcheable

Absolutely! I just submitted an enhancement request at https://bugzilla.mozilla.org/show_bug.cgi?id=1601909 only to find out includeOtherSubdomainsInLookup is going to be removed someday. So I'll either have to browse through dozens of accounts for the domains I manage, or do without Firefox's password manager. Definitely not an improvement.

Does Safari and/or Chrome have the same problem or do they have some heuristic to not offer other logins when there are many? Bug 1561647 would reduce the amount of space the popup takes.

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

(In reply to Alexander Balagurov from comment #3)

Just for the off-topic: Why the hell this feature exists? What is purposed for???

See the User Story field of bug 589628. It's something that Chrome and Safari also do since it really helps for those two use cases.

Ok, it should support subdomains, and maybe even enabled by default, but please consider allowing to disable it - there are other use cases where this feature is a real disadvantage, as explained above.

If this makes sense for some domains, there are situations where this is really a misfeature. History has led various departments of the company I work for to create multiple sites, each with their own id/password. As a result, I now see tens of suggestions whenever I use any of these services. This bringss more confusion than help.

One possible way would be to allow both behaviors depending on user choice for a given domain :

When the list of suggestions is long (length can be set in about:config), the first option in the list could be "Use more accurate suggestions for foo.bar domain" or "narrow suggestions for foo.bar domain" which would disable this feature for that n+1 domain.

PS
Setting signon.includeOtherSubdomainsInLookup preference in about:config to false is not a solution. It's a temporary workaround.

If you are going to support sub-domains, or other hosts in the same domain (Which is the behaviour I'm experiencing), then at the very least restrict the selection of saved logins to those that share a comon username that is in use at the active site.

If we have:
John.smith
From this web site

Then allow this in the list of offered logins:
john.smith
elsewhere@mydomin

But this should NEVER happen (and it is).
superuser
domaincontroler@mydomain

The current behaviour is a misfeature that seems to be actively promoting the sharing of passwords between different logins.

I've been cursing FireFox ever since the "Firefox now suggests saved logins from other subdomains of a site" was implemented.
For me it displays over 700 accounts and always the top one is the one I need.
I noticed it displays any login with my e-mail address domain in it... and the delay between loading the login page and displaying the login suggestions is 10 seconds causing havoc to my workflow..my desktop is otherwise very fast, so it's not my hardware.
Anyway, I found the signon.includeOtherSubdomainsInLookup and set it to false, and it imediatly fixed my issue, I can work again.
I was almost switching to Chrome :(
Thank you !

Fix proposal

There should be a clear distinction between
(a) logins that have been saved for the current site (old behavior, the "From this website" entries)
(b) other logins that are presented as a convenience

In day-to-day use, only category (a) is relevant. To avoid user confusion and to speed up user interaction, only category (a) should be presented in the autocompletion popup by default.

Category (b) should be presented as a single popup item that allows a user to choose a different login if they don't find what they need. E.g. as an item "Show Related Logins" at the end that expands to the related logins (for those rare situations where this functionality is actually useful).

(In reply to Gavin from comment #10)

If you are going to support sub-domains, or other hosts in the same domain (Which is the behaviour I'm experiencing), then at the very least restrict the selection of saved logins to those that share a comon username that is in use at the active site.

There isn't a way for us to know which usernames are to be used on a given site as A user could have multiple accounts on the same site but only have saved the first one on that site so far.

Re-stating my proposals from #589628:

1. Don't show logins from other subdomains if there actually are logins for this exact subdomain and
2. limit the list of "foreign" proposals to max. 2 or 3 (and have a link to see them all in a new tab)

Reasons:

For 1., I really see no reason to propose a "foreign" login if there are already logins for this exact domain.

2. is just to make the interface less overwhelming. If there are more than 2 or 3 possible candidates to choose from, the long dropdown is not the best UI to make that selection.

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

Does Safari and/or Chrome have the same problem or do they have some heuristic to not offer other logins when there are many? Bug 1561647 would reduce the amount of space the popup takes.

You mentioned it multiple times. Does it means Firefox will become a perfect clone of the other browsers ? I hope not.

(In reply to Chris Vigelius from comment #15)

Re-stating my proposals from #589628:

1. Don't show logins from other subdomains if there actually are logins for this exact subdomain and
2. limit the list of "foreign" proposals to max. 2 or 3 (and have a link to see them all in a new tab)

Reasons:

For 1., I really see no reason to propose a "foreign" login if there are already logins for this exact domain.

2. is just to make the interface less overwhelming. If there are more than 2 or 3 possible candidates to choose from, the long dropdown is not the best UI to make that selection.

This seems to be the best thing to do. If you have a saved login for the current subdomain, what would be the benefit of showing all other subdomains saved passwords ?

Why not just let users choose the previous or new behaviour by setting a config key to true/false? (no need to find a way to differentiate usernames, etc.)

(In reply to Chris Vigelius from comment #15)

1. Don't show logins from other subdomains if there actually are logins for this exact subdomain and
   THIS

2. limit the list of "foreign" proposals to max. 2 or 3 (and have a link to see them all in a new tab)
   I dunno why this feature needed. Even if you have exact the same login passwords woll be different in 99.9% of cases

There are two issues with the feature as currently implemented.

1. DNS eTLD + 1 does not always map to the desired authentication domain. I've seen environments where the auth domain was eTLD + 2, eTLD + 3, even 4+. There needs to be a way to change this on a per-credential level, so that a credential can be shared for *.spam.ham.eggs, another for *.bar.baz, and potentially another for the overlapping *.foo.bar.baz .

2. Some credentials such as break-glass superuser may be local to a specific host and should never be supplied to another domain name. This is the degenerative form of the above problem.

I think that storing a domain-component based scope for each saved credential would fix the problem in both cases. The interface can offer a sane default for newly stored credentials, and should allow an easy way to change the scope of an existing stored credential when it is offered.

Yes - we need a way to turn this "feature" off...

Hey Timea, could you see how Chrome and Safari handle having 10+ logins for different username/password combinations for different subdomains? Is there some threshold at which the behaviour changes?

Thanks

(In reply to [:philipp] from comment #1)

if you want to go back to the old behaviour, you can you can change the signon.includeOtherSubdomainsInLookup preference in about:config to false.

That won't be supported forever though it's okay in the short term.

please do NOT take that away.

So I used the same set of saved credentials saved on different Facebook subdomains and compared the suggestions dropdown for:
Firefox Beta
Chrome
Microsoft Edge Chromium
Safari

• Safari restricts the dropdown length to the first 5 entries and a half. The first usernames listed are all from the domain/subdomain the user opened at that moment. The dropdown is scrollable and all the other credentials from different subdomains can be viewed if the user wants to.

• Chrome is even messier than Firefox. The credentials are not filtered at all for the current domain and the length of the dropdown hits the windows taskbar.

• Microsoft Edge Chromium displays everything without even mentioning the site.

IMHO, aside from restricting the dropdown to show only the first 5-6 entries at the beginning (like Safari does), maybe it would be even better to restrict the dropdown length to show the user only the credentials saved on the current domain/subdomain but allow him to scroll through the dropdown and see all the other credentials from different subdomains.

Hope this comparison and all the other user feedbacks raised some context and ideas to improve what we have so far.

IMHO, aside from restricting the dropdown to show only the first 5-6 entries at the beginning (like Safari does), maybe it would be even better to restrict the dropdown length to show the user only the credentials saved on the current domain/subdomain but allow him to scroll through the dropdown and see all the other credentials from different subdomains.

It will not work in my use-case listed earlier. So it should be switcheable in settings

(In reply to Alexander Balagurov from comment #28)

IMHO, aside from restricting the dropdown to show only the first 5-6 entries at the beginning (like Safari does), maybe it would be even better to restrict the dropdown length to show the user only the credentials saved on the current domain/subdomain but allow him to scroll through the dropdown and see all the other credentials from different subdomains.

It will not work in my use-case listed earlier. So it should be switcheable in settings

By earlier comment, do you refer to comment 5? Because I think it's unclear why your case would be special: even with 200 dev subdomain instances, you should get only the "from this site" entries at the top of the list, then the other suggested entries. If something similar to the safari solution would be applied to the 200 entries list, you'd only get 5 or 6, which would be the relevant ones for the subdomain you're on, for the rest you would have to either autocomplete or scroll.

(In reply to Adrian Florinescu [:aflorinescu] from comment #29)

If something similar to the safari solution would be applied to the 200 entries list, you'd only get 5 or 6, which would be the relevant ones for the subdomain you're on, for the rest you would have to either autocomplete or scroll.

I mean that other suggested passwords (from other subdomains) will be useless at all. So it will be great to turn off suggestions entirely

(In reply to Alexander Balagurov from comment #30)

(In reply to Adrian Florinescu [:aflorinescu] from comment #29)
I mean that other suggested passwords (from other subdomains) will be useless at all. So it will be great to turn off suggestions entirely

Same for me.

(In reply to Timea Cernea [:tbabos] from comment #27)

Hope this comparison and all the other user feedbacks raised some context and ideas to improve what we have so far.

Thank you very much for the great comparison Timea! I think the approach of Microsoft Edge Chromium with the footer showing but also scrolling after N logins is best IMO (bug 1561647) [leaving our existing layout for the saved login rows though]. I know Katie from UX already asked for bug 1561647 recently so let's make that the plan for now. We will leave the about:config preference for now.

I think that there has to be a way (checkbox) to enable or disable this functionality.

It is too annoying if you do not benefit of it (for us working in bigger sites or with multiple user on subdomains) - the only option today is not offer any stored passwords, which is not a good option - it is also inconvenient.

Even if you remove all stored passwords for a site (it is rather hard to find the same set of stored passwords in Lockwize which is given in the dropdown), it is quite annoying that the view saved passwords drop down will show even if there is no usernames to show for the current domain (including subdomains). This functionality to offer view saved passwords with no alternatives is so super annoying and occurs if you have devices with no username and only stored passwords for a subdomain.

I think that there is no other option than to introduce a checkbox to enable or disable this functionality to offer sub domain saved passwords.

The current behavior is probably best for most users so there should be some way of maintaining that and also making things easier for corporate users. This is what I think might satisfy that:

Saving the logins:

create an entry including the subdomain
if the domain is new to the password manager
  then create a second entry for the domain without the subdomain

Populating the login

if there is an exact match with the current subdomain and domain
  then autofill with those credentials
elsif there is one submatch
  then autofill with those credentials
else
  then don't populate

So, If I login at bob.facebook.com I will get entries for bob.facebook.com and facebook.com. Then when I login at joe.facebook.com, the form will be filled out with the credentials from facebook.com. Casual users will never know the difference.

If I login at staging.mycorp.com I will get entries for staging.mycorp.com and mycorp.com. Then when I login at prod.mycorp.com the form will autofill with credentials from mycorp.com, so I change the credentials. This will then add an entry for prod.mycorp.com that will be used for logins there from now on. Again, hopefully casual users wont have to dig into config.

If I am a power user I can go into the password manager and change the domain only entry to change the default.

Hi all, [I'm new to bugzilla forum, but proud user of Firefox and Mozilla (thank you!) products from decades. In this, I am talking from the perspective of an average user (not developer or so).]

I would like to bring your attention to the relation of the credentials filling new behaviour with the traditional form autofilling behaviour. I supposse (from the observed new behaviour) that form autofilling is not now applied to username fields, whereas before not only it was applied, but it was one of my main resources for quick credentials filling.

Context: I am in a corporate environment, say "foobarfoo.com" (that is, I would like to note the length of the sites/user strings), with 30+ subdomains, each with own user/pass. First thing to note: for most of them, user is "abcdefghijk" (say for "site1.foobarfoo.com"), but for some sites it is "abcdefghijk@foobarfoo.com" (say for "site7.foobarfoo.com"): that is, not exactly the same string. Second thing to note: I only saved a few of the passwords of the 30+ subdomains, all of them with username "abcdefghijk" (but a complication of the problem could be that the saved string were shorter, "abcd" for example). Third: in fact, most of the subdomain sites used LDAP (I think it is the name), that is, the pass of most of the sites is my corporate pass, and that is precisely the reason because I do not want to save the password.

Behaviour before. (1) When I went to "site1.foobarfoo.com" only have to write "a" as username, the form autofill suggested and filled "abcdefghijk", then tab to pass field, typed the pass, and login. (2) When I went to "site7.foobarfoo.com" only have to write "a" as username, the form autofill suggested and filled "abcdefghijk@foobarfoo.com", then tab to pass field, typed the pass, and login. For me, very efficient in both cases.

Behaviour now for the two sites. No username suggested, only dropdown menu (it is OK, from the credentials filling perspective). (1) In "site1.foobarfoo.com", I select one entry (because the username matches, at least), but I have to delete the autofilled password. (2) In the case of "site7.foobarfoo.com", (a) if I do not select a saved entry, I have to write the entire "abcdefghijk@foobarfoo.com" string, (b) if I select an entry, I have to return to the user field to complete "@foobarfoo.com", then tab to the pass field, and delete it. Significantly more typing work than before.

That's my user experience, I feel it is a bit poorer than before.

We will start by implementing bug 1631617 and there is a workaround with signon.includeOtherSubdomainsInLookup=false in about:config so lowering the priority.

What bugs me most, is the security issue of presenting wrong credentials with the domain only being displayed in light grey, reducing redability (consider gamma setting on displays). The color also suggests that the domain matches is less important for the login than that the username matches. Personally, I tried to login with the wrong credentials several times. If a system were infected, the malware it could have received my credentials for a system not infected, which would allow it to extend infect the healthy system. Firefox suggests random passwords for new accounts, which is great, but that is less usefull if it sends the generated passwords to the wrong systems.

As the selection of the credential is a boring routine activity users probably try to reduce the duration of the task and therefore make errors. However, a single wrong selection could cause a password to be compromized.

So I support the proposal of Max Keller, i.e. only show exactly matching credentials and show other possibly matching credentials only on request in a dialog box (or extend the list or so). I would extend his proposal by the possibility for the user to link a credential to multiple (sub)domains so that credential then exactly matches the new (sub)domain and is displayed prominently. That could happen automatically when the user selects a possibly matching credential from the dialog and submits the form.

As this is a security issue, please increase the priority.

I'm experiencing a variant of this: not subdomains, but subfolders.
I have a website that uses the same domain for everything, no subdomains, and has different apps deployed as subfolders, such as /blog, /tasks, /gallery, etc. and the problem is that for all these entries, Firefox suggests the various different usernames (and different passwords) and marks them all as "From this website", which makes it impossible for me to remember which is which. From my user's perspective, in this case, different usernames on different subfolders are not the same thing, they are not "from this website" because each app is technically a different website, although not on a different subdomain.

Does that case constitute a different-enough usecase that I should file a separate bug report for it, or it's considered to be the same and simply commenting here is enough?

(In reply to Jeff Fortin from comment #41)

Does that case constitute a different-enough usecase that I should file a separate bug report for it, or it's considered to be the same and simply commenting here is enough?

That case is bug 263387, which as you'll see has many many duplicates.

I think the perfect solution would need two changes, but definitely #1 here would help a lot:

the most relevant saved login/s (matching subdomain, maybe even matching folder) should be listed on the top.
If you want to be nice, then either a different background colour or a separator line should be used when any other less-relevant passwords are listed in addition.

an ability to disable a single saved login from being listed anywhere but at the saved subdomain
Example; if I'm in a local dev enviro, I might want to lock a saved login at client1.local.test to just that single subdomain.
This could be achieved by a simple flag in the password management to filter it out when the program picks up the ones it should offer by domain.

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:serg, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.