> > > > For the real submission case, I guess what we want is a way to say > > "autocomplete=off" after the fact, basically. An HTTP header seems > > like the most obvious solution. > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > Again, these need multiple vendors on board to make progress. > > Browsers are moving away from respecting autocomplete=off. I don't think > we should be adding a new but basically equivalent mechanism. > > While I agree that it's a concern, I'm not overly worried that this is going to be abused for a few reasons.
1) We talked to some major US banks when disabling autocomplete=off for passwords, and though they historically have been a big proponent of the feature they didn't seem bothered that it was no longer going to be respected. It seems like sites are more accepting of password managers now. I wouldn't be surprised if a reasonable percentage of autocomplete=off usage is just inertia at this point. 2) A well-intentioned site might use autocomplete=off thinking that it's a security benefit to their site. Doing this with this new API would be obvious abuse and it doesn't seem likely that a site would do it unless they were looking for some way to block password managers. 3) If a site really wants to go out of their way to make sure that password managers don't work on their site, there are already ways of doing it. This would be an easier mechanism, but I'm not sure how much that matters. If we still think that this is too likely to be abused, another possibility might be to only allow the site to assert login succeeded not that it failed. Not sure how useful that is though, since it's generally easier to prompt on incorrect login than miss a correct login. > > 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. > > > > 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. > > In most of the cases that I've seen where this comes up (e.g. Pandora) it seems like the entire site does navigation via AJAX + history.pushState(). It doesn't seem like the site is trying to avoid password managers so much as they are trying to keep the aesthetic of their site consistent. > > The requestAutocomplete() API is a Chrome proprietary feature right > > now so it's sort of acadmic, but: > > > > Why would this only apply to requestAutocomplete()? Surely it would be > > just as important for the case where the user agent is filling in a > > form without using that API. > > Agreed. I don't see the benefit of requestAutocomplete() here. > > > Ted >
