This has been driving me nuts! Do we have have a meta bug tracking sites where password auto-fill fails?
autocomplete=off strikes again. Login Manager: Counting logins matching host: https://mozilla.okta.com formSubmitURL: httpRealm: null PwMgr json: _searchLogins: returning 1 logins PwMgr json: _countLogins: counted logins: 1 Login Manager: Searching for logins matching host: https://mozilla.okta.com formSubmitURL: https://mozilla.okta.com httpRealm: null PwMgr json: _searchLogins: returning 1 logins PwMgr cryptoSDR: SDR slot status is 5 PwMgr json: _findLogins: returning 1 logins Login Manager (content): form not filled, has autocomplete=off Login Manager (content): autocomplete=off but form can be filled; notified observers From HTML: <form action="/login/do-login" method="post" id="credentials" class="v-form" autocomplete="off">
We probably need to consider whether or not we should give the user a visible pref (or polaris-like single pref) to ignore autocomplete="off"
Solving this bug would likely fall into the category of "fallback UX" for when we fail to auto-fill a password but have one stored. I really feel like it should be up to the user to decide whether or not to fill in a password, especially if one is saved, since my currently workflow is to just open the password manager and copy/paste. Is this a dupe of bug 433238?
I can't figure out why this works, but if you click "Remember me", then the password manager works in the future on Okta. Clicking that doesn't seem to change the autocomplete state, but maybe my dev tools are tricking me. I'm of the opinion that we should always ignore autocomplete=off on password forms, and I'd like a more consistent experience of how I get my password filled when I want it.
Margaret, I don't know of a meta bug for failing sites, but it would be nice to have an easy way to search for them all.
xref bug 1105331 asking for us to request that Okta turns off autocomplete=off.
See Also: → bug 1105331
Safari's password manager gets this right. We fail. Chrome fails. We should fix this.
Duplicate of this bug: 1111699
Note that selecting the login from the autocomplete popup here should work, but doesn't because we pick the wrong password field out of 2 because the form has 2 of them (one hidden) and this code: http://hg.mozilla.org/mozilla-central/annotate/9bb8b0b4daae/toolkit/components/passwordmgr/LoginManagerContent.jsm#l573 says that when you pick the item, it's not a submission (we pass false as the second param to _getFormFields), and so this code: http://hg.mozilla.org/mozilla-central/annotate/9bb8b0b4daae/toolkit/components/passwordmgr/LoginManagerContent.jsm#l406 arbitrarily picks the first one, which is the hidden field, after which no password is filled in in the visible field, which means that submitting the form doesn't work ("password is required"). I don't know if just updating that would help, but it does seem wrong that we pick the other field here - logins.json has the right field id/name, so we should be picking the visible one, which would probably make it easier to cajole the form into working anyway. dolske, what's the right way to fix the above sequence of events so we pick the correct password field?
At the very least it seems like we should filter out hidden password fields from pwFields before picking the first one.
(In reply to :Gavin Sharp [email: firstname.lastname@example.org] from comment #10) > At the very least it seems like we should filter out hidden password fields > from pwFields before picking the first one. ... but only if there are multiple ones? Wouldn't want to break this for forms with a single field that is made visible after you fill in the username, or somesuch.
Sometimes the real password field isn't visible on page load. Check out out http://www.hulu.com/.
We could go the other way and fill in all password fields, but I bet there are edge cases there too.
(In reply to Mark Finkle (:mfinkle) from comment #13) > We could go the other way and fill in all password fields, but I bet there > are edge cases there too. In my experience, that generally works ok, except in the case of signup, change password, and reset password.
(In reply to Gijs Kruitbosch (Gone until Jan 5) from comment #9) > logins.json has the right field id/name, so > we should be picking the visible one, Input names have generally been useless, so we don't use them at all. (They're harmful, really, because they tend to change are used inconsistently on different pages in a site.) > dolske, what's the right way to fix the above sequence of events so we pick > the correct password field? It sure seems to me that Okta is doing this deliberately to break password managers, so I'm afraid anything we do here is only going to be a temporary one-off fix. And then they'll change something else. [And I'm pretty sure Okta didn't do this shortly after we started using them, with autocomplete from the dropdown working fine. So this is a recent change for them.] I'd also worry a bit about this unexpectedly breaking other sites that are hiding the login fields until the user performs some action to display the login UI (hulu.com in comment 12 seems an example like this, but I didn't look in detail). Could be that this would still fix more sites than it breaks, but it's hard to say. Generally, I'd like to keep our default how-to-fill-a-page heuristics as sane as possible, and rely on site-specific tweaks (or "recipes" we've been calling them for 2015 planning) to handle weird cases. I'm on the fence about this being this being something that can be fixed sanely for the default case, though... It wouldn't be too bad to ignore hidden fields only when _some_ are hidden (i.e. if they're all hidden, just do what we do now). That would fix the Okta-case and avoid breaking the Hulu-case. But we'd still be broken for a site that had a form structure like Okta, but kept the whole thing hidden until showing the UI like Hulu. So that's weird and inconsistent. It also starts us down the slippery slope of exactly how hard we try to figure out if something is "hidden", which a site could be doing in many many ways.
Depends on: 1171114
You need to log in before you can comment on or make changes to this bug.