On Fri, Apr 11, 2014 at 3:36 PM, Edward O'Connor <eocon...@apple.com> wrote: > > I actually have a similar problem with purely JS-handled forms even > > unrelated to credentials. Because the form is never really submitted > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > event and handle the work on the JS side), there's never an indication > > to the UA that it should save the fields, and so autofill never works > > right on these forms, even for things like postal addresses or e-mail > > addresses.
In Firefox, we save the form values after validation but before the submit event is dispatched to content. This way we successfully save the form fields in form history when a script is handling the actual submission. This also helps against sites who try to manipulate the form fields upon submission to avoid having them saved (see https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing this for a long time and I don't recall any complaints as long as I've been working on password and form manager for Firefox (since 2009). There are many websites that use click handlers on buttons outside forms instead of using form submission and those fields don't get saved in Firefox. I suspect web developers don't realize that they are losing out on form history and other benefits like being able to submit the form with the Enter key from a text input. I don't see sites that are not having their fields saved by not using form submission switching to calling a new API when they can instead use an onsubmit handler which has other benefits. Given that Firefox already saves values with preventDefault inside form submit handlers and click handlers on submit buttons, and the other benefits of sites using form submission, I don't think a new API is needed. > > For the pure JS case, an API (probably on the <form> itself) would > > make sense and seems relatively easy. I've filed a bug on this: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > This case is pretty weird. Authors are going out of their way to avoid > using the built in platform features that would get them autofill saving > for free. In some cases, they might be doing this precisely because they > want to prevent autofill but can't count on autocomplete=off anymore. It seems like more evangelism is needed to let authors know that preventDefault inside a form submission handler is the better way to handle forms where navigation isn't wanted. The benefits are: form history, password management, better UX (allowing submission via <Enter> when inputs are in a <form>), and possibly better accessibility(?). I've been thinking about cases where we could detect the pattern of fake forms (using text <input>s and <button>s with click handlers together without a <form>) and provide notices in developer tools to help evangelize but it's looking to be tricky. -- Matthew Noorenberghe