Yoav Weiss
Rouslan Solomakhin (Google)
Darwin Yang (Google)
(Shopify)
Dominic Battre (Google)
Christoph Schwering (Google)
- Do we need a mailing list?
- No
- Do we want this to be a regular call?
- No need. We can organize ad hoc calls as needed.
#4 - Filling process
- Yoav: For 1step autofill we would need to align on a schema for sharing the address which seems hard to do. 2step, we would avoid that
- Dominic: do we know that we need more than the country?
- Christian: Province of Region
- Dominic: e.g. Brazilia uses a different address scheme than rest of the country
- Christian: Rural France just got street numbers a few years ago, so could change per area
- .. Talked about 1 step vs. 2 step. How much do we want to rely on the current flow and augment it, vs. the 1 step flow?
- Dominic: What do you have in mind? We observed that people are focused on the field they are currently filling. A top-right dialog may be something people not see. We need to meet people where their attention is
- Rouslan: can we show a dialog where the autofill popup would be?
- Dominic: There’s some precedent for that for permission prompt. For camera, people focus on the button to enable it, rather than the top. Maybe didn’t land
- Christian: Can we reuse the current UI, but allow developers to receive thedata in JS?
- Dominic: would be nice to have something that doesn’t rely on forms, but I’m concerned that autofill rates would drop if we move the dialog
- Rouslan: On Android we’ll use the bottom sheet?
- Dominic: Not today because we don’t know who’s address the site asks for. E.g. sender and receiver
- Rouslan: I thought it would be useful for your address
- Dominic: If the website indicates they really want autofill, we’d show it. Currently only for passwords and credit cards. We currently show address autofill on the keyboard.
- Yoav: we’d love address bottom sheet on Android
- Christian: So it fills both email and address
- Dominic: Trying to help you figure out what you would fill
- Yoav: how do we determine step 1 vs. 2? Ergonomics?
- Christophe: why is 1 step better than hidden fields?
- Christian: we have all the possible fields as hidden fields to try and capture everything
- Christoph: would it be the same in JSON?
- Christian: Currently the values are filled multiple times and we need to coalesce. No province in the select field
- Dominic: Chrome has a lot of logic to handle the provinces.
- Christian: Chrome behaves the best, but we try to be compatible. Some browsers don’t have a second step of autofill after the form changes
- … 2 steps would solve that
- Christoph: what level of adoption would you expect? Some sites to fight us
- Dominic: they may preventDefault
- Christian: Why do browsers want to disable autofill? If we’d improve, would it improve things
- Dominic: Some folks stated “problems with IE6” or “backend system issues with certain characters”
- Christian: some Shopify merchants prefer all the data to be in select fields
- Dominic: So a JSON object would require mapping between the json and their select data
- Rouslan: Chrome knows a lot about regions (abbreviations, local names, translated names). If we give these pieces in the JSON object, can you use the information to display the local name in a div or use the abbreviated name to display it in select
- … It’s better to tell the user what information we’re sharing and then let the website decide what to do with it, without filling in the information in the fields directly.
- Yoav: issues with filling in directly: schema + marking what was filled
- Christian: As a user, if there’s no form I still know something happened. Is this a problem?
- Dominic: Maybe not a problem for the user, but could be a problem for the user because the information is incomplete
- … users may miss the fact that parts of the address are missing
- Rouslan: if there’s no form, that can be problematic
- Christian: At Shopify, we’d still show the form if fields are missing. If the address is complete, we’d still show a condensed version
- Dominic: may not be ideal to do that with autofill. E.g. could be wrong phone number
- Christian: It’d reduce friction if we got it right, but increase friction for users where it’s wrong
- Dominic: Risk, as users will not necessarily check that their information is correct
- Christian: agree on the risk. We can experiment with it
- … So let’s assume we always use a form, how can we avoid relying on hidden fields
- … The two step process?
- Dominic: Flow could be as simple as adding a flag saying “we need a callback”
- … The event handler would look at the form, say “the country has changed” and tell the browser to run autofill again
- … Can also be possible to only fill the country and then wait until the callback
- Christian: Like the first step
- Yoav: So we’re suggesting that the website will have form that is ready to receive an address that may not be accurate. It will get a callback when autofill is triggered, rearrange the form, then tell the browser to trigger again to fill the rest? We had concerns about developer ergonomics.
- Christian: win over status quo. Would help us answer how would the browser know what to fill
- Dominic: and it doesn’t require a schema. It would be useful, but a large effort
- Christian: Thought we can version the schema and progress it over time
- Dominic: Initial schema could be what browsers support today (address line 1,2,3)
- Rouslan: If we’re doing 2 passes, there’s no requirement to introduce a different UI. But is that still interesting? A different UI that shows the full address
- Christian: In our opinion, a user expects their address in a single unit
- Dominic: email and phone number seem separate
- Christian: Looking at the form, I see the fields. But with hidden fields I can’t see what I’m filling
- Yoav: Why we would want to have a different UI? With the second pass on autofill the user is not made aware about all fields. Multiple
- Dominic: want to surface to the user the full information that we’re interested in sharing. The website can opt–in to receiving phone/email or only the postal address
- Christian: Current hidden fields are a privacy mess. This would be an improvement
- Christoph: What do we do about non-addresses? Also, are other browsers interested?
- Yoav: Some browsers don’t want to be coerced into autofilling where they don’t want to autofill. E.g. passwords, x-origin iframes
- Christoph: we only get privacy benefits if websites use it
- … It’s hard for the browser to detect if a field is hidden
- Yoav: heuristics that evolve over time
- Christian: that’s an inherent problem with autofill. Right now autofill hidden is easy. Need to make it work well without
- Christoph: what about non address data?
- Christian: address is the big problem because of dynamicity
- Christoph: the problem is we’re using the fields to preview the data. Using a different UI for that can help
- Dominic: We could even delete the preview and just enable the popup
- Rouslan: so talking about showing the full address in the autofill popups
- … So we don’t necessarily want the preview, as it could get complicated
- Dominic: it would be a tradeoff. In most cases websites are good at predicting your country (sell to single market, different domains)
- … So in many cases the form would already be correct
- Christian: there are cases where the user is buying in one country and shipping in another. Websites where people don’t buy for themselves. Filling in the email drags the address in
- Dominic: Gifting seems different as you don’t have other people’s addresses in autofill. But traveling is probably a good case
- Christoph: Not sure we have good data regarding select elements
- Dominic: Select elements are a challenge for us. If a site doesn’t use regular select elements the JSON form can help
- … recently looked at a website where the country selected changes the entire address form
- Christian: In different countries you have different shipping requirements, so that can change as well (e.g. phone numbers)
- Dominic: phone numbers are broken due to truncated prefixes (the “0” before the local code if there’s no country code)
- … Autocomplete spec says that phone country code should be +1, but there are multiple countries for it. So we need to fill country, not country code
- Yoav: Looks like we are converging on 2step process.
- Christian: 2 step is good enough. Would solve the problem
- Dominic: Could be multiple steps. Website can tell the browser multiple times “please fill again”
- Christian: would autofill happen automatically after the callback? Or an API you can call from anywhere?
- Dominic: The website would need to do an async operation
- Yoav: TaskAttribution can help (currently Chromium only)
- Dominic: the website would tell the browser “fill the address again”, not specifically regarding a certain field
- Christoph: you mentioned phone numbers, should the site tell the browser it wants a phone number
- Dominic: if we move in the direction of the direction of “drop down shows everything”, we’d need the website to tell the browser what it needs
- Yoav: we can figure out the opt-ins, no complexity there. So 2 steps it is
- Dominic: makes the project easier to ship
Autofilling of credit card fields in different iframes
- Christian: one more thing to discuss, if the goal is to remove hidden fields we also need a solution for credit cards
- Dominic: Christoph has a solution for that
- … For credit cards, the problem goes away if same-origin iframes all get filled in a single pass
- … e.g. sites put the credit card holder in the main frame, but filling the credit card info in cross-origin iframes
- Christian: for PCI compliance
- Dominic: if they’d move it, we could fill the credit card data in a single origin
- Christoph: that works in Chromium browsers
- … Other browsers don’t seem interested in cross-frame credit card forms
- … One or two Chromium extensions just autofill everything across origins
- … other browsers fill the fields in one document and not across documents
- … Some PSPs figured it out and use hidden fields
- Yoav: with PCIv4 we can remove the iframes because they are no longer a compliance boundary
- Christian: sites will be slow to adapt
- Dominic: So we expect more websites will do a full redirect to the PSP, to avoid PCI compliance
- Christian: That’s indeed the easier way, worse for UX
- … We’ll expand our PCI compliance to the entire checkout page
- … PCIv4 takes into effect in March ‘25.
- … PCI compliance involves process as to who can commit code, etc. Now that applies to the top-level page
- <discussion on PCI compliance and PSPs>
- Yoav: better to tackle addresses first
- Christian: websites may want to keep the credit card in a separate iframe, maybe to protect against XSS