Disclosure: I work for AgileBits, makers of 1Password.
I was diagnosing an issue with 1Password failing to offer to save user’s credentials when clicking the “Log In” button in the modal sign in dialog. The main issue turned out to be that the “Log In” <button> is not a child of the <form> that it controls and does not have a form attribute set. With these kinds of orphaned elements, 1Password is much more reserved about its interpretation of the user’s clicks.
I arrived at a solution that will work around this in the 1Password extension, but it would be more semantic if Discourse’s buttons were either children of their <form> elements or had explicit relationship set up via the form attribute.
It would also be appropriate to explicitly set the type attribute of this button to “submit”. Even though this is the default attribute value, apps like 1Password look for an explicit attribute because lots of sites use buttons with no type attribute for things that do not have a submit behavior.
I got as far as tracking this down to login.hbs:43 and was going to make a PR to add the form="login-form" attribute, but had some issues getting the dev environment set up and ran out of time so I punted to creating a bug report. 
Thanks!
–
Jamie Phelps
Code Wrangler @ AgileBits
Fort Worth, Texas
1Password. Thanks for taking the time to describe both the issue and the solution.