Password not auto-filled on mozilla.okta.com

RESOLVED FIXED

Status

()

Toolkit
Password Manager
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: Margaret, Assigned: MattN)

Tracking

Trunk
Points:
1
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 1120129], URL)

(Reporter)

Description

3 years ago
This has been driving me nuts!

Do we have have a meta bug tracking sites where password auto-fill fails?
Flags: needinfo?(ckarlof)
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"
(Reporter)

Comment 3

3 years ago
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.
Flags: needinfo?(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.
xref bug 1105331 asking for us to request that Okta turns off autocomplete=off.
See Also: → bug 1105331

Comment 7

3 years ago
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?
Flags: needinfo?(dolske)
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: gavin@gavinsharp.com] 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.
Flags: needinfo?(dolske)
https://hg.mozilla.org/integration/fx-team/rev/4f28f9c87ba6#l2.207
Assignee: nobody → MattN+bmo
Status: NEW → RESOLVED
Iteration: --- → 39.2 - 23 Mar
Points: --- → 1
Last Resolved: 3 years ago
Depends on: 1120129
Flags: qe-verify-
Flags: firefox-backlog+
Resolution: --- → FIXED
Whiteboard: [fixed by bug 1120129]
Depends on: 1152422
No longer depends on: 1152422
See Also: → bug 1152422
You need to log in before you can comment on or make changes to this bug.