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

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

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

Reply via email to