(In reply to Daniel Veditz [:dveditz] from comment #1)
given that we autofill forms without user interaction.
which is, of course, password manager's original sin. I do not understand out complete rejection of addressing that point.
There isn't a complete rejection of this… that's why we added the user-visible pref in about:preferences#privacy-logins last year. I've commented somewhere else before that we want to get the password manager working well before hindering the UX by not autofilling. In order to have a decent UX comparable with other browsers it's not as simple of changing the default value of this pref… Chrome still autofills AFAICT and Safari only stopped autofilling when they added auto-submission of login forms. Implementing the latter is quite difficult (adding even more heuristics to password manager which is complicated enough) and error-prone making it not a priority at the moment.
Using the (eTLD+1) instead of full domain in a secure context (e.g.
https: page) won't make us much less secure. Will it solve your problem, though?
Anecdotally I think it will help a large proportion of the 17% as I've seen subdomains changing between the following common subdomains: 'www', 'secure', 'login', & 'm'.
After landing this change we should be able to approximate the effect by looking for a decrease in
AUTOFILL_RESULT.NO_SAVED_LOGINS telemetry as it's fairly stable. If you aren't objecting to this change then I'd like to try it, with a pref to revert if necessary.