1101026 - Password not auto-filled on mozilla.okta.com

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect)

Description

[:Margaret Leibovic]

This has been driving me nuts!

Do we have have a meta bug tracking sites where password auto-fill fails?

Comment 1

[Justin Dolske [:Dolske]]

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

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

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"

Comment 3

[:Margaret Leibovic]

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?

Comment 4

[Chris Karlof [:ckarlof]]

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.

Comment 5

[Chris Karlof [:ckarlof]]

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.

Comment 6

[Mark Banner (:standard8)]

xref bug 1105331 asking for us to request that Okta turns off autocomplete=off.

Comment 7

[Asa Dotzler [:asa]]

Safari's password manager gets this right. We fail. Chrome fails. We should fix this.

Comment 9

[:Gijs (he/him)]

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?

Comment 10

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

At the very least it seems like we should filter out hidden password fields from pwFields before picking the first one.

Comment 11

[:Gijs (he/him)]

(In reply to :Gavin Sharp [email: [e-mail]] 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.

Comment 12

[Chris Karlof [:ckarlof]]

Sometimes the real password field isn't visible on page load. Check out out http://www.hulu.com/.

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

We could go the other way and fill in all password fields, but I bet there are edge cases there too.

Comment 14

[Chris Karlof [:ckarlof]]

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

Comment 15

[Justin Dolske [:Dolske]]

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

Comment 16

[Matthew N. [:MattN]]

https://hg.mozilla.org/integration/fx-team/rev/4f28f9c87ba6#l2.207