Affected Versions:
Nigthly 87.0a1 (2021-02-09)
Beta 86.0b7
Release 85.0.1

Tested On:
MacOS 10.15

Steps to Reproduce:

1. Go to gap.com and reach the login form: https://secure-www.gap.com/my-account/sign-in
2. Submit one set of credential and save them
3. Log out of the Gap account and reload the login form
4. Check the login fields.

Expected:
The autocomplete dropdown should not be toggled considering there is only one saved login.

Actual:
Autocomplete dropdown is toggled on page load. Please see the screencast for more details https://imgur.com/EVVtUR1

Notes:

• Reproducible on Chrome? No
• Regression of Bug 786276, pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dff33d0b33c8fb168966504f5562572ddec72a8e&tochange=4a2a0128e6ec425bec21c1ceb3e323818b3bf8b5

I would argue that this is expected behavior given bug 786276. Since the iframe that Gap uses for their login is not the same origin as the page itself (their iframe is hosted at api.gap.com, while the page itself is secure-www.gap.com), we wouldn't want to autofill in order to protect the user. Of course the user wouldn't know why the autofill did not happen, but we're presenting the autocomplete dropdown, so we aren't stopping them from using their saved credentials.

:sfoster I'm leaning towards invalid/won't fix, since we can't do anything about Gap's iframe origin. Do you have any strong opinions? I'm not sure how we have historically resolved these kinds of issues.

Agreed, this is expected behavior. Its interesting that Chrome has a different take.. The differing origins are invisible to the end-user, so I can see this being a source of some confusion, but this is exactly the scenario that bug 786276 fixed. We have no way of knowing currently that api.gap.com should be trusted as being the same entity as secure-www.gap.com, so not autofilling is the right thing to do here.