Add an autofill module

[yoavweiss]

This is a PR similar to w3c/webdriver#1797, but on the BiDi side.

It adds a trigger autofill command that would enable developers to trigger autofill on one of the page's elements with specified data provided to the command: either credit card information or an address.

/cc @sadym-chromium

---

Preview | Diff

[jimevans]

@yoavweiss Does this proposal depend on the user agent (the browser) supporting autofill? What if the browser doesn't support this feature? Is it dependent on the autofill portion of the HTML Living Standard? Is it expected that the property names in the autofill store for testing map must match the autofill field name tokens? If not, what are the restrictions on the property names, if any?

[yoavweiss]

@jimevans - I thought that using a "should" language in "The [=user agent=] should [=autofill=] |element| and |element|'s [=form owner=], while taking into account the contents of |store|" would be enough to ensure that user agents that don't support autofill would still be compliant. I'm happy to add an explicit condition to that effect.

Is it dependent on the autofill portion of the HTML Living Standard? Is it expected that the property names in the autofill store for testing map must match the autofill field name tokens?

It does. I guess I didn't make this dependency explicit. I'll take a stab at that.

[OrKoN]

It looks like the preview has not been regenerated for some reason (I am still seeing the save command).

[martinLechnerShopify]

@OrKoN I've addressed all your comments, would you be able to give it another pass? Thanks in advance!

[yoavweiss]

/cc @galich - I'd love your thoughts on this :)

[OrKoN]

Generally, the approach LGTM but I wonder what @jgraham @whimboo @gsnedders think.

[martinLechnerShopify]

Hi @OrKoN , coming back from a 2-weeks vacation, I wanted to check in and see where we stand with this PR - is this ok to be merged, so we can move on to the implementation phase? Thanks in advance for a quick update!

[OrKoN]

@martinLechnerShopify we need the approval from other browser vendors as well to merge this

[martinLechnerShopify]

@OrKoN thanks, is there some kind of regular "sync" or a timeline when other browser vendors are usually commenting/approving? I'd like to make sure we can push this over the finish line together in a reasonable timeframe.
Thanks in advance!

[OrKoN]

The meeting happens on the second Wednesday of the month. @AutomatedTester is the chair and the organizer of the meeting. @yoavweiss already presented in the proposal in one of the previous meetings https://www.w3.org/2024/05/08-webdriver-minutes.html

[OrKoN]

LGTM (% we could add a note that the intention of the method is to test the actual implementation of the autofill component in the browser as realistically as possible and not to implement a different WebDriver-BiDi-specific form filling method)

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Autofill trigger.

The full IRC log of that discussion

<tidoust> Topic: Autofill trigger
<tidoust> github: https://github.com//pull/706
<tidoust> Yoav: Adding an autofill trigger, discussed at last TPAC. Help website trigger autofill and check it does the work for both addresses and cards.
<tidoust> ... This is useful today for web sites to test autofill. Similarly useful for future proposals.
<tidoust> ... Would love to get opinion from folks on the overall feature as well as on the specifics of the PR itself.
<sadym> q+
<jgraham> ack next
<jgraham> q+
<tidoust> sadym: The PR looks generally good. My only concern is about what happens when the browser autofills. Not sure the spec is detailed enough. Otherwise, generally positive about this!
<jgraham> ack next
<Yoav> q+
<orkon> q+
<sadym> q+
<tidoust> jgraham: I haven't looked at the updated PR. Being able to test autofill in general makes sense. I don't know if it's a top priority for us as we haven't heard feedback from lots of users, but no objection!
<jgraham> ack Yoav
<jgraham> q+
<tidoust> Yoav: On the spec front, I can see a specification that outlines how a browser should match the provided inputs. One potential thing that makes me hesitant about this is that this may not match how autofill is currently implemented in browsers. This should trigger autofill as browsers implement it, which is somewhat heuristics based.
<jgraham> ack next
<tidoust> .... Specifying a step-by-step algorithm may not work, unless there are provisions for the heuristics.
<sadym> q-
<bburg> q+
<tidoust> orkon: We do have this functionality in Puppeteer, and it's similar to what is being proposed.
<sadym> q+
<tidoust> ... Users report that it's useful to test if their website works with autofill.
<tidoust> ... I also agree it's only useful if it tests the actual implementation of autofill.
<jgraham> ack next
<tidoust> ... There are edge cases, such as when iframes are considered, and goal is for users to test under real conditions.
<tidoust> jgraham: It's useful to hear that there's demand for it.
<tidoust> ... The way you would fill out the data, then load the page again, and ask the browser whether it has autofill data for this page. And then you would inspect which fields were filled out.
<Yoav> q+
<tidoust> ... That would be something you could standardize without trying to standardize specific heuristics.
<jgraham> ack bburg
<tidoust> bburg: Two parts in Safari. What type of form? And do we have data to fill it?
<tidoust> ... It's rather opaque when we offer autofill or not. Some performance related considerations.
<tidoust> ... There are all kinds of heuristics. Web sites do all sorts of things, including multiple form elements. We cannot rely on semantics only, there's a lot of logic and heuristics involved.
<tidoust> ... We don't want to expose that complexity. We just want to expose the classification.
<tidoust> ... We kind of need to define what we are testing specifically. What are we hoping to get out of it? The actual data we put in? A field type?
<tidoust> ... Lots of questions on how you would be going up about that.
<tidoust> ... Having some tests that would use this thing would be useful.
<tidoust> Yoav: We're not talking about login forms, only addresses and credid cards, which is potentially simpler or more complex.
<tidoust> ... One thing we could do in terms of form classification is an error code [missed details].
<tidoust> bburg: It's still slippery.
<tidoust> Yoav: I would expect the browser to apply its heuristics on the address, and then the user would check whether the field was filled out as expected.
<jgraham> ack sadym
<Yoav> q-
<tidoust> sadym: Apparently, autofill is split into 3 tasks: detecting the form (very implementation specific), checking the data, filling the form. This PR is about the third one. I would propose to split these 3 tasks separately.
<tidoust> jgraham: More discussion in the PR, then.
<tidoust> RRSAgent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/09/10-webdriver-minutes.html tidoust
<jgraham> Zakim, bye
<Zakim> leaving. As of this point the attendees have been jdescottes, jgraham, orkon, jimevans, tidoust, Yoav, shs, sasha, sadym
<bburg> woops

[sadym-chromium]

@yoavweiss please wait for at least one other vendor to approve the PR

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Autofill trigger.

The full IRC log of that discussion

<AutomatedTester> topic: Autofill trigger
<AutomatedTester> github: https://github.com//pull/706
<jgraham> q+
<AutomatedTester> sadym: this PR has been sitting there and we need to have other vendors review so that we can unblock and get this landed
<AutomatedTester> ack next
<AutomatedTester> jgraham: I havent had time to look but I think the last time this was discussed and it needed changes but there doesn't appear to have been updated. I will need to re-read the PR
<AutomatedTester> q?