Re: [whatwg] Various autocomplete="" topics

On Mon, May 5, 2014 at 10:38 PM, Matthew Noorenberghe <
MattN+whatwg@mozilla.com> wrote:

> On Fri, Apr 11, 2014 at 3:36 PM, Edward O'Connor <eoconnor@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.
>

The problem right now is that there are two legitimate reasons that a site
may return false from the submit handler, either because the submission
failed validation in some way or because submission is being handled via
script. Browsers can either ignore this distinction (e.g. Firefox) or try
and separate the two heuristically (e.g. Chrome). Both are reasonable
approaches given the current state of the world, but neither are ideal. We
should allow sites to make this distinction.

I agree that we shouldn't necessarily add contortions for sites that don't
use form submission, but currently there isn't a right way to do this even
if the site wants to.


> > > 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
>

Received on Friday, 16 May 2014 22:12:10 UTC