[web] Fix grouped autofill on iOS Chrome

[flutter-zl]

Fixes #185327

Problem

On iOS Chrome, Chrome Password Manager did put the saved password into Flutter Web's hidden browser input. But Flutter Web still thought the password field was empty, so when it refreshed the autofill form, it copied that old empty value back into the browser input. The password was erased before it showed up in the visible Flutter TextField.

Fix

Before copying Flutter's stored value into a non-focused autofill field, Flutter Web now checks what is already in the browser input. If the browser input already has a password that Flutter has not seen yet, Flutter Web sends that password to the framework and leaves the browser input alone instead of clearing it.

To avoid mistaking a deliberate app change for an autofill, it tracks the last framework value for each field, carried
over when the autofill form is reused. A value the app changed programmatically is still pushed into the DOM; only an
unchanged framework value sitting next to a changed DOM value is treated as a browser autofill.

Demo

iOS Chrome:

• Before: https://flutter-demo-34-before.web.app - username fills, password stays empty
• After: https://flutter-demo-34-after.web.app - username and password both fill

[gemini-code-assist]

Code Review

This pull request introduces tracking of the last sent autofill text to preserve dormant autofill values when a form is restored, along with a corresponding test. The review feedback identifies a potential regression where programmatic updates from the framework to non-focused fields could be ignored or reverted, and suggests tracking the last processed framework text to distinguish between programmatic updates and browser autofill events.

[mdebbar]

The symptoms sound very similar to this issue: #177248

When the hidden input's value is updated, does it receive focus first or does it get updated without a focus event?

[flutter-zl]

The symptoms sound very similar to this issue: #177248

When the hidden input's value is updated, does it receive focus first or does it get updated without a focus event?

1. I measured it on a real iOS Chrome device with a focusin/input probe: the hidden password input is updated
   without a focus event. The browser fires input and change on it while document.activeElement stays on
   the focused username field, and no focusin ever lands on the password field.

2. Different failure mode from [web] Autofill does not work on browsers running on iOS 26 and iPadOS 26 devices #177248 though. That one is total autofill failure on iOS 26 across browsers; here autofill partially works, the focused username fills but the non-focused password is lost on iOS Chrome, while iOS Safari fills both.

[mdebbar]

1. the hidden password input is updated
   without a focus event. The browser fires input and change on it while document.activeElement stays on
   the focused username field, and no focusin ever lands on the password field.

This case is supposed to be handled by:

flutter/engine/src/flutter/lib/web_ui/lib/src/engine/text_editing/text_editing.dart

Lines 442 to 456 in 8cffb53

	subscriptions.add(
	DomSubscription(
	element,
	'input',
	createDomEventListener((DomEvent e) {
	if (items[key] == null) {
	throw StateError('AutofillInfo must have a valid uniqueIdentifier.');
	} else if (key != focusedElementId) {
	// `input` events on the focused element are handled elsewhere.
	final AutofillInfo autofillInfo = items[key]!.autofillInfo;
	_handleChange(element, autofillInfo);
	}
	}),
	),
	);

[flutter-zl]

1. the hidden password input is updated
   without a focus event. The browser fires input and change on it while document.activeElement stays on
   the focused username field, and no focusin ever lands on the password field.

This case is supposed to be handled by:

flutter/engine/src/flutter/lib/web_ui/lib/src/engine/text_editing/text_editing.dart

Lines 442 to 456 in 8cffb53

	subscriptions.add(
	DomSubscription(
	element,
	'input',
	createDomEventListener((DomEvent e) {
	if (items[key] == null) {
	throw StateError('AutofillInfo must have a valid uniqueIdentifier.');
	} else if (key != focusedElementId) {
	// `input` events on the focused element are handled elsewhere.
	final AutofillInfo autofillInfo = items[key]!.autofillInfo;
	_handleChange(element, autofillInfo);
	}
	}),
	),
	);

Yes, that path should handle non-focused input events while the form is active.

The difference here is timing: in this repro, the password appears to be written after DefaultTextEditingStrategy.disable() has canceled the autofill input subscriptions, but while goDormant() keeps the form in the DOM for browser autofill. So the DOM input gets the password, but Flutter no longer has that listener attached to call _handleChange.

Then when the dormant form is reused, wakeUp() calls _updateFieldValues(), which previously copied the framework's stale empty value back into the non-focused password input.

[harryterkelsen]

LGTM

[auto-submit]

autosubmit label was removed for flutter/flutter/187459, because The base commit of the PR is older than 7 days and can not be merged. Please merge the latest changes from the main into this branch and resubmit the PR.