Meeting minutes
yoav: This is a proposal we talked about during last years TPAC
… a few things happened since
… being prototyped in Chromium, but hasn't landed yet
[Proposal - WICG/
yoav: Autofill is awesome
… Shopify stats say great things about autofill - 1/3rd of guest checkouts use autofill, and have a 41% increase in completion rate
… Good from our perspective, also good for user
… At the same time, current autofill model is aimed at static forms
… particularly for addresses, this is not how things work in real life
… different countries have different address structures and requirements
… so people use hidden form fields in order to get ALL the possible required data, then reshuffle the form in DOM and show the user
… This is bad for the merchant from a complexity perspective
… This is bad for a user because hidden forms are hidden and they aren't aware of what has been filled until its done
yoav: Shopify came up with a proposal to help solve this
… an Autofill event that fires after autofill has happened
… event gets passed autofill values (may not be needed?)
… and a refill promise, that when resolved, taking in account users permission/settings
… will then re-fill the new fields
[Yoav shows example script]
yoav: The reshuffling could be sync or async, depending on page structure, server side rendering, etc
… We also wanted to discuss a 'full-address' autocomplete attribute value on the form
… Not currently needed for Chrome based on its Autofill security model, but maybe needed for other browsers?
… The question is, without this attribute, how does the browser know what to show the user?
… We want the user to give knowing consent to what will be filled
… We're not very sure about this, would love feedback
yoav: Once this all happens, and is in the wild for long enough, maybe browsers could deprecate autofilling of hidden fields, which would be more private for users
yoav: Open questions:
… 1. Do we need the autofill_values in the event at all? This was from original proposal which was sync BEFORE autofill, now its async AFTER autofill, so you can just refill the form
… 2. How would browser extensions that provide autofill-like facilities deal with this mode? Just haven't thought about it.
christian: I'm glad the second open question is here
… if there's a more-structured way for the autofill data to be accessed by the webpage, is direct DOM manipulation still useful?
… what if we just give the site the data in some structured template
… always been a hit and miss for all browsers for filling certain forms, conflicting with things like key events and so on
yoav: We heard objections from Chrome team that they want to show the user that certain data was autofilled, and paint it in certain ways
stephen_mcgruer: +1
ricky: Autofill is magic, its incredible, we ask developers to do basically no work, and we save humanity a billion hours a day
ricky: I used to maintain safari's heuristics for autofill in a past life, nowadays I work on authentication
… In safari, my recollection is that we decided that when a form asked for *anything* related to address, and user was doing a one-shot autofill, our UI would show everything - even things that weren't being filled
… After we're done filling, we wait a beat and re-process, and re-fill out
… It's not great. It would be good to know when the work is done
(get clarification on what the current proposal)
ricky: That seems reasonable
… One thing I do have battle scars from is websites thinking they should fight autofill
yoav: Yep. From my perspective, the repo is titled address autofill. Primarily from feedback of this exact same scenario
… I'm only interested in addresses, maybe we should call the event address autofill?
[We briefly touch on autocomplete=off]
ricky: I don't think anyone listens to that in password anymore
… in non-password cases, some user agents listen to it in certain cases
… that's where we're all at?
[Yes, generally]
stephen_mcgruer: Just wanted to ack that we also have automatic refill in Chrome
ricky: Scoping this to not all autofill but certain kinds does seem interesting
ricky: For the attribute that can express that the form may change dynamically , that sounds good. More metadata, lets you do better UX
ricky: For hidden fields, I think safari doesn't do it
???: For [lastpass? onepass? sorry I missed it], I don't think we fill hidden fields either
???2: (Describes a scenario where iframe across origins goes wrong)
lychee: I can attest to that. For Meta IAB, we ran an experiment where we took Chromium's ability to detect hidden fields and ran an experiment [scribe missed details]
… we found that there's a gazillion ways to hide a field
ricky: +1
lychee: We actually did this to solve a shopify issue, where each iframe has a separate fields and so we would have a visual indicator
stephen_mcgruer: Should we start an autofill CG?
(This was a joke, but the room says "yes" across four different autofill implementations!)
yoav: So I'm hearing support for address autofil
… would credit card autofill look similar
… the whole multiple frame problem is also interesting here
… the event would fire on each one
… that might be hard to implement on the browser side?
stephen_mcgruer: I do have some concerns
(we discuss what happens if multiple refill calls happen - wait for the last? how?!)
???1: How would this work across iframes?
yoav: I think fires on each iframe, each one does some update, they coordinate? Or they each resolve the promise? And if they each resolve, then when do we do the refill.
… Definitely an open question!
ricky: Take the common frame ancestor and dispatch autofill on that one
ricky: parent frame is coordinating the inner frames? Or are they sandboxed?
yoav: May be sandboxed, but they have to send that information somehow
yoav: I don 't know how common multiple-iframe is for address forms
lychee: Billing address tends to be in an iframe
… I have seen sites where shipping address is in the main frame, but then everything billing address is in the iframne
stephen_mcgruer: So all in the same iframe, that sok
lychee: But we may want to fill both shipping and billing
stephen_mcgruer: One hard thing btw is "what is an address" to each autofill implementor
ricky: We should game theory out the 'other things on the page can listen to this', but I think its fine
ricky: For the third item about one day not filling hidden fields. Thats at the autofill implementors discretion
… I think its a bit different
yoav: This is here, because we thought all browsers are autofilling (known) hidden fields, which is problematic
… definitely not required
yoav: So overall I'm hearing yes, we need an autofill CG, and this proposal sounds worthwhile to people?
(Assent)
(With the general expectation to propose changes that would end up in WHATWG probably?)
yoav: Implementation-specific question for Safari - how much Autofill is in WEbKit?
ricky: Very little
???3: With a slightly growing amount, but still not a lot
yoav: I'm interested in the hooks to implement this programmatic refill
… how much of this could I help write?
ricky: In safari's case, not implementable in webkit
???3: It could be
ricky: if you have a bug report for automatic refill not working in Safari btw, please do file it. Happy to look at it
yoav: Related work - we had a parallel stream that looked at testdriver for uatofill
… we wanted to have fake WPTs to reproduce where we hit snags across different implementations
… waiting on implementor interest
ricky: I will come back on that
lychee: On the open questions - do we need autofill_values? I don't have an opinion. Yoav may be the best to answer?
yoav: I agree, probably more of a developer question
… will come back with an answer
lychee: For autofill_values, were you thinking the values that had been filled in, or the full address autofill values?
yoav: The values that are already filled in?
stephen_mcgruer: Do you want the values we *tried* to fill in, or the values that were filled?
ricky: This gets close to doing a full schema again, re requestAutocomplete
yoav: Yes, full schema not in scope
… What we did for the prototype, was play back the form in JSON format for the event, but that was when it was BEFORE fill
yoav: I think we should drop it unless we have a use case
ricky: I suspect you can skip user preference part under hidden fields
yoav: Yeah, need to rewrite that part
lychee: Sounds like (3) is a nice north start that we won't hit practically
yoav: Yeah, lets make it long term aspirational and non-commital
schwering: I have a few questions related to hidden fields
… Are you proposing to make this address specific?
… When we relate this to hidden fields, what about all the other types we may fill
… Wouldn't it be unfair to say we stop filling hidden fields?
stephen_mcgruer: So hidden fields are definitely not in scope
… for the address specific, I think we should name the event generic and then only fire it for what the implementor thinks is good
yoav: What if we later figure out that creditcard event has to be a specific subtype
???2: I like the idea of using options, because its easier to forward-deploy it for websites, as opposed to having to write generic code from day 1
yoav: Options at event listener to listen to a specific type?
ricky: That kind of narrowing down is dangerous
… you can introspect your own form to see what tpye it was? Is that good enough vs the weight of a contract
(we discuss all the groups writing down what they think an address is :D)
???1: There is literature that exists for defining what an address is out there, which is relatively recent...
(stephen_mcgruer describes Chrome's address type)
(???1 describes 1pass's giant text blob that they introspect!)
(lychee describe's meta representation - similar to Chrome)
yoav: This has been great, great feedback
… I feel setting up a CG to talk about this and potentially other autofill things feels like a good direction
… thank you everyone!
yoav: This proposal is in WICG
WICG/
… Please file issues! I will polish it up, this is my focus until end of year.
RRSAgent: make minutes