(In reply to Ian 'Hixie' Hickson from comment #0)
> If you've submitted a login form, but the credentials were wrong, it would
> be nice if the site could say "don't bother saving those credentials, they
> were bad".
> 
> Maybe an HTTP header.

1. An HTTP header (perhaps `Login-Disposition: [ 'success' / 'failure' ]`?) makes a good deal of sense to me.

2. It would be nice to support a declarative form of this header as part of the HTML document. This might be as simple as `<meta http-equiv="Login-Disposition"
contents="success">`, but it might make sense to add an explicit extension to the registry.

One thing that I'm slightly worried about is that some sites will use this as a new form of autocomplete="off" and always return 'Login:Failure'. I think that we still want to do this as the information is useful in the general case, just wanted to bring it up. I doubt that there is much we can do about it.

Mike, can you elaborate on why it would be useful to have this in HTML itself?

Garrett, any idea how we could avoid that?

Adoption is the simplest reason: for better or worse, it's easier to convince authors to add a meta tag than it is to adjust their headers. Even in cases where there are clear security benefits to the header (CSP), we still see significant <meta> usage (for example, G+ was using it until recently).

I don't know if we can prevent sites possibly abusing this, but really if they are trying to be user hostile and break password saving there are already ways to do it (e.g. using <input type="text"> with JS to hide the password). It's also not clear to me if sites that are using autocomplete=off really think that password saving is bad and how much is just inertia. When we talked with banks about removing this feature, there very little push back.

If anyone can think of a simplistic way to prevent abuse it seems worth considering, but I wouldn't hold this feature up because of it.

Matt, any feedback on this one?

I've talked with teammates about doing something like this recently. We (Mozilla) previously experimented with something like this the Account Manager experiment with Labs (although that was more complex and included the login state with the username in a HTTP header).

In Firefox we currently show the prompt to save/update even before the form submit event, instead of waiting for submission, but at that time we don't know whether the page is going to stop the submission via preventDefault (in which case we still want to show the prompt but wouldn't want to wait for the HTTP header from the request which isn't going to happen). We would likely have to switch to gathering data to save before submission and then figuring out whether there was going to be a navigation to @action after the submit listeners run in order to know whether to show UI then or after getting the HTTP headers. This sounds like a big enough change that it's hard to know how well this will work at this time. There would be new complexities such as properly cleaning up/overwriting the state while also handling repeating a form submission in the event of network issues upon first submission.

I have concerns with the UX of this change too e.g. on a slow/flaky network, the delay before showing UI asking to save/update may have more of a negative perception than the current problem of offering to save an incorrect password.

Side note: IMO the summary of this bug should be more specific to refer to login forms and not any form submission. e.g. if the form doesn't have @type=password, is there still a reason we would want to honour this for form history?

I also had abuse concerns like Garrett brought up.

In summary, I think this is something that would be nice to address at some point but there are enough @autocomplete changes to deal with and I don't think the current failure case is that bad/common that I don't think this is a priority for us at the moment.

It's also worth considering if it's actually ok just to save the password every time anyway, since the next time the user logs in, if we save the password, it'll just override the wrong one, in which case who cares if we saved the wrong one...

If this is still desired, please file a new issue over at https://github.com/whatwg/html/issues/new. Thanks!