[web] Autofill all AutofillGroup fields in semantics mode - #187108

Similar to the WebKit check in text_field.dart, using ui_web.browser.isSafari here misses other WebKit-based browsers (like Chrome/Firefox on iOS) when semantics mode is active. Consider checking if the browser engine is WebKit to ensure synthetic fields are not zero-sized on any WebKit-based browser, which would defeat autofill.

Done.

Casting editableElement directly to DomHTMLInputElement can lead to runtime type errors if the field is a multiline text field (which uses DomHTMLTextAreaElement). Since both input and textarea elements support the name attribute, you can safely use editableElement.getAttribute('name') to avoid any unsafe casting.

Done.

I want to check if my understanding is correct: in semantics mode, we create the <form> and all text fields inside it, and then we delete the "focused" one because we want to use the semantics field.

If my understanding is correct, imagine a simple form of username and password. In the semantics tree, we create a username field and a password field. Then the user focuses on the username field, so we create the form, and we create an extra password field inside it. Now we have one username field and two password fields. Is this the case?

I think in semantics mode, the _createFormElementAndFields() method should only create the form, no fields, because the fields are already created in the semantics tree.

1. It's "skip," not "create then delete", the focused field is never synthesized:

   if (field... == focusedAutofill.uniqueIdentifier) {
     if (associateFocusedByAttribute) {
       continue; // focused field stays in <flt-semantics>, linked via form=
    }
     htmlElement = focusedElement;
   } else {
    // synthetic for non-focused fields
   }

2. So with username focused: username = one element (the real semantics input, linked by form=, not
   duplicated); password = the idle semantics input + one synthetic in the form, but only the synthetic is in
   the form.

3. The form can't be empty, though: the semantics password isn't inside the form, so the browser won't group it. The synthetic is its in-form stand-in and value relay (browser fills it → listener forwards to the framework → AutofillScope writes it to the real field). Same path semantics-off uses. And the focused field stays in its semantics node because moving it into the form broke a11y tab order (Fix a11y tab traversal flutter-team-archive/engine#25797).

It's "skip," not "create then delete", the focused field is never synthesized

Ah you are right. I was confused by the synthetic.remove(); line. Can we delete it? Maybe replace it with an assert to make sure no synthetic element was created for the focused ID.

The form can't be empty, though

The form is never empty. There's always at least a submitBtn in it.

the semantics password isn't inside the form, so the browser won't group it.

Can we do the same form= attribute for non-focused fields too?

1. synthetic.remove() is only for waking a dormant form where a previous blur left a placeholder, not for deleting something created during the initial form build. The first-build case is already enforced by the continue in _createFormElementAndFields: the focused field is not synthesized when the form is first created in semantics mode.

2. Agreed that “empty form” was imprecise. The form always has submitBtn.

3. For non-focused fields, this code path cannot use form= today. EngineAutofillForm only receives the focused semantics DOM element. For the other fields it only has AutofillInfo, not the real SemanticTextField.editableElement, so it cannot attach form= to them. The synthetic controls are also the relay path for browser autofill values via TextInputClient.updateEditingStateWithTag.

Non-focused fields can use SemanticsTextEditingStrategy.instance.inputConfiguration.autofillGroup!.formDomId to get the ID for form=. I don't know what's the best place to do this, but maybe in the update() method?

Right.formDomId is reachable from update().

The blocker is that form= alone only associates the element with the form. It does not tell the browser or Flutter which autofill field this semantics input represents.

For example, if we only add form= to the password input, we get:

<input form="login-form">

But for browser autofill and framework value propagation, the real field would also need the matching AutofillInfo metadata:

<input
  form="login-form"
  name="current-password"
  autocomplete="current-password">

Today that DOM-element-to-AutofillInfo mapping only exists for the focused text input client. For non-focused fields, the synthetic inputs are created directly from the group's AutofillInfo, so they have the correct name, autocomplete, and tag for TextInputClient.updateEditingStateWithTag.

So I think keeping the synthetic non-focused fields is safer for this PR.

What if someone call wakeup with associateFocusedByAttribute: false and then call it with associateFocusedByAttribute: true?

It feels like associateFocusedByAttribute should be a constructor parameter of EngineAutofillForm so that we don't need to worry about the mismatch

Great suggestion. Updated.