566290 - [accounts] Firefox doesn't remember passwords on account form

Status: RESOLVED FIXED

(Webtools Graveyard :: Elmo, defect, P2)

Description

[Axel Hecht [:Pike]]

The new account form doesn't remember passwords, but I don't know why.

Possible culprits could be:

The form is loaded via async XHR and inserted into the doc with innerHTML.

The form is starting off with display:none, and is only shown on click.

STR: Hit the "log in" link at the top left of https://l10n-stage-sj.mozilla.org/, log in. Log out. Hit "log in" again, and no password help. The password is stored, though.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

My bet is on the former. If the form is loaded via XHR, it is not part of the web page and will not be autofilled.

Comment 2

[(no longer active)]

Shouldn't this bug be moved to Toolkit::Password Manager?  This webapp cannot be the only one which does this!

Comment 3

[Axel Hecht [:Pike]]

I think it's fine for the pwmgr to not support what we do, in a sense.

It'd be nice for there to be an API to trigger pwmgr explicitly, though.

Background: If I read the code right, pwmgr kicks off on DOMContentLoaded, which I guess is right. Now, we insert the form after that, so the pwmgr would need to listen to modification events. Ugh, bye bye perf, hello loneliness. The RFE would be for content to trigger an event (on the form?) that it'd love to the pwmgr to come in again and have a look.

Comment 4

[Staś Małolepszy :stas]

To work around this in the dashboard, could we {% include %} the form when the template renders, hide it, and make it submit via ajax?

Comment 5

[Axel Hecht [:Pike]]

No, the whole point of the current code is to make the majority of the page not depend on the user's account, and thus being able to cache that piece.

The solution is likely to add a js version that document.write()s the account snippet.

Comment 6

[Rimas Kudelis [use needinfo to ping]]

I think regardless of whether or not it would be solved, a bug for Toolkit::Password Manager should be filed. Ehsan is right, it's very unlikely that we're the only ones having a login form inserted dynamically after a page loads.

Comment 7

[(no longer active)]

(In reply to comment #3)
> I think it's fine for the pwmgr to not support what we do, in a sense.
> 
> It'd be nice for there to be an API to trigger pwmgr explicitly, though.
> 
> Background: If I read the code right, pwmgr kicks off on DOMContentLoaded,
> which I guess is right. Now, we insert the form after that, so the pwmgr would
> need to listen to modification events. Ugh, bye bye perf, hello loneliness. The
> RFE would be for content to trigger an event (on the form?) that it'd love to
> the pwmgr to come in again and have a look.

I don't think that this is necessarily true.  We could raise a custom notification when a form element is bound to the tree and let password manager handle it (we at least do it in one other case, the "earlyformsubmit" notification).  No need for mutation observers.

Comment 8

[Peter Bengtsson [:peterbe]]

I think Stas is right, the best solution would be to include the login form, always, but hidden. This makes the page aggressively cacheable yet you get the desired effect as a user. 

I've added a new bug which I'm pretty sure will solve this by 
https://bugzilla.mozilla.org/show_bug.cgi?id=658966

Comment 9

[Peter Bengtsson [:peterbe]]

As of https://bugzilla.mozilla.org/show_bug.cgi?id=658966 this is now resolved. It does remember the password.